plan-delta
Create step-by-step implementation plan for a delta
What this skill does
# Implementation Plan Workflow
Create an implementation plan for a specific delta.
## Input
Delta ID from: $ARGUMENTS (e.g., "DLT-001")
## Context
**You must load the following skills and read the following files before proceeding.**
### Skills
- `katachi:framework-core` - Workflow principles
- `katachi:working-on-delta` - Per-feature workflow
- `katachi:research-docs` - Awareness of documentation research workflow
### Delta inventory
- `docs/planning/DELTAS.md` - Delta definitions
### Delta documents
- `docs/delta-specs/$ARGUMENTS.md` - What to build (requirements)
- `docs/delta-designs/$ARGUMENTS.md` - Why/how (design rationale)
### Project decisions
- `docs/architecture/README.md` - Architecture decisions (ADRs)
- `docs/design/README.md` - Design patterns (DES)
### Feature documentation (for reconciliation planning)
- Read affected feature specs from delta-spec's "Detected Impacts" section
- Read affected feature designs from delta-design's "Detected Impacts" section
- Plan should note which feature docs will need reconciliation after implementation
### Existing plan (if present)
- `docs/delta-plans/$ARGUMENTS.md` - Current plan to update or create
### Template
- `${CLAUDE_PLUGIN_ROOT}/skills/working-on-delta/references/implementation-plan.md` - Structure to follow
## Pre-Check
Verify spec and design exist:
- If `docs/delta-specs/$ARGUMENTS.md` doesn't exist, suggest `/katachi:spec-delta $ARGUMENTS` first
- If `docs/delta-designs/$ARGUMENTS.md` doesn't exist, suggest `/katachi:design-delta $ARGUMENTS` first
- Plan requires both spec and design
## Process
### 1. Check Existing State
If `docs/delta-plans/$ARGUMENTS.md` exists:
- Read current plan
- Check for drift: Have spec or design changed?
- Summarize: batches, steps, context entries
- Ask: "What aspects need refinement? Or should we review the whole plan?"
- Enter iteration mode as appropriate
If no plan exists: proceed with initial creation
Update status:
```bash
python ${CLAUDE_PLUGIN_ROOT}/scripts/deltas.py status set $ARGUMENTS "⧗ Plan"
```
### 2. Research Phase (Silent)
- Read delta spec (`docs/delta-specs/$ARGUMENTS.md`)
- Read delta design (`docs/delta-designs/$ARGUMENTS.md`)
- Read relevant ADRs and DES patterns (not just indexes)
- Read dependency code as needed
- Explore codebase for implementation patterns
- Build complete understanding without asking questions
### 3. Scope Batches (Present All at Once)
Identify natural implementation boundaries and define all batches. Present them together to the user for validation before expanding any steps.
For each batch, define:
- **Scope name**: What part of the feature it covers (model layer, service logic, API endpoint, frontend, etc.)
- **Context & Research list**: Specific entries with reasoning — project docs (spec sections, design sections, ADRs, DES), code files to read, and external research pointers (library docs, existing patterns to investigate). Each entry must explain *why* it's needed for this batch. When a batch involves external libraries or frameworks, include a research pointer directing the implementing agent to follow the `katachi:research-docs` skill guidance for those libraries to verify current APIs before writing code.
- **Out of scope**: What this batch explicitly does not cover
- **Dependencies**: Which batches must complete before this one starts (`Depends on:` field)
Present the batch definitions to the user. The user validates:
- Batch boundaries make sense (logical grouping, clear scope)
- Context is appropriately scoped (not too broad, not missing obvious things)
- Dependencies and ordering are correct
- Research pointers are concrete and relevant
Iterate on batch definitions until the user approves them.
### 4. Expand Steps and Research (Silent)
For each batch, draft the implementation details:
**Steps:**
- Draft implementation steps following the same granularity rules as before (atomic, verifiable, in dependency order)
- Each step specifies: files to create/modify, what to do, how to verify
**Research pointers:**
- Identify where the implementing agent should look things up (library docs, patterns to extend, design questions to investigate)
- Add these as entries in the batch's Context & Research list
- Re-check: does this batch's context actually match its steps? Add missing entries, remove entries that don't apply
**Code snippets:**
- Use snippets to indicate implementation points (where to add code)
- Include brief comments explaining what should happen at each point
- Do NOT include complete implementation logic
- The implementation agent has access to spec, design, ADRs, and DES patterns — the plan provides structural guidance, not code
Example of appropriate snippet usage:
```python
# In src/services/auth.py, after the existing validate_token function:
# Add new function here to handle token refresh
# - Should follow DES-002 error handling pattern
# - Must validate refresh token expiry per spec AC-3
```
### 5. External Validation (Silent)
Dispatch the plan-reviewer agent to validate the complete plan:
```python
Task(
subagent_type="katachi:plan-reviewer",
prompt=f"""
Review this implementation plan.
## Delta Spec
{spec_content}
## Delta Design
{design_content}
## Implementation Plan
{plan_content}
## Relevant ADR/DES Summaries
{adr_des_summaries}
"""
)
```
### 6. Apply Validation Feedback (Silent)
Review the plan-reviewer findings and apply improvements:
- Address coverage gaps (missing acceptance criteria)
- Fix dependency ordering issues between steps and between batches
- Fix batch context scoping issues (over-scoped or under-scoped entries)
- Resolve ADR/DES conflicts
- Incorporate suggested improvements
If the reviewer identified critical issues that require clarification, note them for discussion with the user.
### 7. Finalize
Save the plan to `docs/delta-plans/$ARGUMENTS.md`.
Update status:
```bash
python ${CLAUDE_PLUGIN_ROOT}/scripts/deltas.py status set $ARGUMENTS "✓ Plan"
```
Present summary of the completed plan:
```
"Delta plan complete for $ARGUMENTS.
Batches:
- [Batch 1 scope name]: [one-line description]
- [Batch 2 scope name]: [one-line description]
- ..."
```
## Workflow
**This is a validate-first process with progressive disclosure:**
- Research silently, then scope batches
- Present all batches for user validation
- Expand steps silently for all batches
- Validate complete plan (batches + steps) with plan-reviewer agent
- Apply validation feedback
- Save and present summary
Related in General
modeling-omnistudio-epc-catalog
IncludedSalesforce Industries CME EPC product-modeling skill for Product2-based catalog creation. Use when creating EPC products, configuring product attributes, building offer bundles with Product Child Items, or reviewing EPC DataPack JSON metadata for product catalog changes. TRIGGER when: user creates or updates Product2 EPC records, AttributeAssignment payloads, AttributeMetadata/AttributeDefaultValues, Offer bundles, or ProductChildItem relationships. DO NOT TRIGGER when: designing OmniScripts/FlexCards/Integration Procedures (use building-omnistudio-omniscript, building-omnistudio-flexcard, or building-omnistudio-integration-procedure), implementing Apex business logic (use generating-apex), or troubleshooting deployment pipelines (use deploying-metadata).
relationship-science-coach
IncludedUse this skill for direct, practical adult relationship coaching: couples conflict, repair, trust, marriage, dating, flirting, attachment patterns, emotional connection, sex, desire differences, eroticism, kink negotiation, affection, love languages, breakups, and long-term passion. Draw on Gottman, EFT and Hold Me Tight, attachment science, modern sex research, Perel, Nagoski, Kerner, Schnarch, Love and Stosny, and flexible love-language tools. Be concrete and low-hedge. Redirect only for imminent danger, abuse, coercive control, minors, non-consent, self-harm, stalking, or medical/legal/psychiatric decisions.
building-sf-integrations
IncludedSalesforce integration architecture and runtime plumbing with 120-point scoring. Use this skill to set up Named Credentials, External Credentials, External Services, REST/SOAP callout patterns, Platform Events, and Change Data Capture. TRIGGER when: user sets up Named Credentials, External Services, REST/SOAP callouts, Platform Events, CDC, or touches .namedCredential-meta.xml files. DO NOT TRIGGER when: Connected App/OAuth config (use configuring-connected-apps), Apex-only logic (use generating-apex), or data import/export (use handling-sf-data).
venue-templates
IncludedAccess comprehensive LaTeX templates, formatting requirements, and submission guidelines for major scientific publication venues (Nature, Science, PLOS, IEEE, ACM), academic conferences (NeurIPS, ICML, CVPR, CHI), research posters, and grant proposals (NSF, NIH, DOE, DARPA). This skill should be used when preparing manuscripts for journal submission, conference papers, research posters, or grant proposals and need venue-specific formatting requirements and templates.
let-fate-decide
IncludedDraws the 12 Houses of the Zodiac Tarot spread to inject entropy into planning when prompts are vague, ambiguous, or casually delegated. Interprets the spread to guide next steps. Use when the user says 'let fate decide', 'YOLO', 'whatever', 'idk', or other nonchalant phrases, makes Yu-Gi-Oh references, or when you are about to arbitrarily pick between multiple reasonable approaches. Prefer over ask-questions-if-underspecified when the user's tone is casual or playful rather than precision-seeking.
net-ops
IncludedCross-platform network troubleshooting (Windows, macOS, Linux) via local or remote shell. Use for: DNS broken, can't resolve hostnames, nslookup/dig works but apps fail, NRPT, WFP, scutil, /etc/resolver, systemd-resolved, /etc/resolv.conf, NetworkManager, VPN DNS leak residue (ProtonVPN/Mullvad/WireGuard/AnyConnect), AV/firewall blocking DNS or DoH, Tailscale DNS interaction, intermittent connectivity, remote diagnostics over SSH.