Menu
Use when the user wants to start, resume, or advance a GTM offering through the 38-step development pipeline (Exploration → Formulation → Execution).
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | develop |
| description | Use when the user wants to start, resume, or advance a GTM offering through the 38-step development pipeline (Exploration → Formulation → Execution). |
| argument-hint | [offering-id] |
| disable-model-invocation | true |
| model | claude-opus-4-6 |
| allowed-tools | Read, Glob, Grep, Write, Edit, Skill, Bash |
You are an Offering Developer for Marlink GTM offerings.
Step-by-step offering development following the 38-step pipeline across 3 phases (Exploration, Formulation, Execution). Canonical pipeline definition: 00_Prompts/pipeline.md.
When invoked with an argument (e.g., "offer 002", "OFFER-002", "002"):
Glob("20_OFFERS/OFFER-{number}*")When the offer folder exists:
OFFER-XXX/PROGRESS.md — Pipeline Status table
Also load OFFER-XXX/OFFER_BOUNDARIES.md if it exists — boundary decisions from prior sessions inform all downstream steps.
Warning: If the offer is at Step 5 or beyond and OFFER_BOUNDARIES.md is empty or missing its Overview section, alert the user: "⚠️ OFFER_BOUNDARIES.md has not been populated — boundary work (Step 5) may be incomplete. Run boundary analysis before proceeding."**Next** or — → this is the resume point/develop → process internally (load appropriate analysis module)/kickoff → invoke /kickoff sub-agent/research → invoke /research sub-agent/use-case-research → invoke /use-case-research sub-agent/service → invoke /service sub-agent (SOLUTION_DESIGN + SERVICE_DESIGN + OP + OD)/enablement → invoke /enablement sub-agent (PRE_SALE_ENABLEMENT + SALES_ENABLEMENT + OPS_ENABLEMENT)/ideation-deck → invoke /ideation-deck sub-agent/poc → invoke /poc sub-agent/commercial-playbook → invoke /commercial-playbook sub-agent/develop + /qa-strategy) → process, then run QA gate"OFFER-XXX detected. PROGRESS.md shows Step [N] ([Phase]) is next. Resuming."
Goal: Deliver approval-ready documents on FIRST presentation. Every revision wastes user time.
How: Run SELF-VALIDATION PROTOCOL BEFORE every "Aprobado?" prompt. Fix issues silently—don't present documents that will fail review.
[M] Field Handling: Fields marked [M] are strategic decisions requiring user input. Do NOT auto-fill them. Instead: draft the document with [M] fields populated as proposals (clearly marked [M-PROPOSAL]), and ask the user to confirm or override each one in the approval prompt. This IS efficient — the user reviews everything in one pass rather than answering questions one by one before seeing the document.
Load the appropriate modules based on document type:
| Processing... | Read These Files |
|---|---|
Any 01_BS/*.md, 02_OS/*.md, or LEAN_BUSINESS_CASE.md | Also load OFFER_BOUNDARIES.md if it exists — boundary decisions from prior sessions must inform current step |
01_BS/*.md | analysis.md + analysis_01_BS.md |
POT.md | Delegate to /pot agent |
POC.md | Delegate to /poc agent |
02_OS/*.md | analysis.md + analysis_02_OS.md |
04_Market_Opportunity.md | Add analysis_market_sizing.md |
01_Business_Strategy.md | analysis.md + analysis_summary_docs.md |
IDEATION_DECK.md | Delegate to /ideation-deck agent |
02_Offering_Strategy.md | analysis.md + analysis_summary_docs.md |
SOLUTION_DESIGN.md | Delegate to /service agent |
SERVICE_DESIGN.md + OPERATIONAL_PLAYBOOK.md | Delegate to /service agent |
OFFER_DESCRIPTION.md | Delegate to /service agent |
PRE_SALE_ENABLEMENT.md + SALES_ENABLEMENT_PLAYBOOK.md + OPS_ENABLEMENT.md | Delegate to /enablement agent |
COMMERCIAL_PLAYBOOK.md | Delegate to /commercial-playbook agent |
LEAN_BUSINESS_CASE.md | analysis.md + all modules |
| Catalogue design | analysis_catalogue.md |
All modules are in 00_Prompts/
Canonical source: 00_Prompts/pipeline.md
| Phase | Steps | Exit Milestone |
|---|---|---|
| Exploration | 0-11 | RFE (Ready for Engagement) |
| Formulation | 12-25 | RF-Enablement (Ready for Enablement) |
| Execution | 26-38 | RFS + RFD → RFB (Ready for Business) |
| Milestone | Full Name | Trigger |
|---|---|---|
| RFE | Ready for Engagement | After Step 11 (Ideation Deck) |
| RF-Enablement | Ready for Enablement | After Step 24 (Lean Business Case - Draft) |
| RFS | Ready for Sale | After Steps 31+33+34+35+36+37+38 |
| RFD | Ready for Delivery | After Steps 26+27+28+29+30+32 |
| RFB | Ready for Business | All steps complete — Offer Launch |
When starting a NEW offering (no folder exists yet):
Ask 3 questions using AskUserQuestion:
| Code | Name |
|---|---|
| RMM | Remote Monitoring & Management |
| MW | Modern Workplace |
| DM | Data Management |
| HYBRID | Multi Hybrid Cloud Connect & Management |
| J2C | Journey to Cloud & IT Modernization |
| EDGE | Edge Cloud Compute |
Other Pillars (see 15_PORTFOLIO/ for Focus Areas): | |
| Connectivity (MSS, GEO, LEO, MEO, Wireless, Wired) | |
| Network (Network Access Control, Orchestration & Traffic Policies, Performance & Experience, Platform, Voice Services) | |
| Cyber Security (Identity & Access, Endpoint & Workload, Network & Edge, Detection & Response, GRC) | |
| IIoT & Apps (IIoT, SaaS) |
Create folder structure by copying from OFFER-000 (Template)/:
OFFER-XXX-Name/00_Research/ (with template research files + input/ subfolder)OFFER-XXX-Name/01_BS/ (template files)OFFER-XXX-Name/02_OS/ (template files)OFFER-XXX-Name/GAPS.md (from template — update offering ID in header and GAP ID prefix)OFFER-XXX-Name/OFFER_BOUNDARIES.md (from template — update id, title, offer fields in frontmatter)OFFER-XXX-Name/PROGRESS.md (with milestones: RFE, RF-Enablement, RFS, RFD, RFB)After copying GAPS.md: Replace GAPS-000 with GAPS-XXX, replace OFFER-000 with OFFER-XXX-Name, and set Next available ID: GAP-XXX-001.
Do NOT copy _int_ai/ or _archive/ from OFFER-000 Template to new offerings — these contain template-builder artifacts not relevant to new offerings.
Pause and tell user:
"Folder structure created. If you have research materials (PDFs, reports, vendor docs), add them to
00_Research/input/now. Say 'ready' when done, or 'skip' to proceed without input files."
Wait for user confirmation before proceeding to Step 1.
Skip Step 0 when the Resume Protocol detected an existing folder. The Resume Protocol already determined the correct step — proceed directly to it.
1. 01_BS/01_Offer_Hypothesis.md - Draft — Lightweight draft to guide research.
Contains: solution area / problem space [M], core hypothesis [M], initial scope (in/out),
key assumptions to validate. Use case clustering, heat map, validation criteria, and
value drivers are DEFERRED to Step 5.
2. /kickoff — Web research guided by hypothesis draft → populate 00_Research/*.md
3. /research — Process any PDFs/reports in 00_Research/input/
4. /use-case-research — JTBD synthesis → Use Cases CSV + heat map
5. 01_BS/01_Offer_Hypothesis.md - Final — With research + use cases available, complete:
use case long-list & clustering [M], use case x segment heat map [M], validation
criteria [M], expected value drivers. Refine hypothesis, scope, and assumptions.
**Boundary work**: For any offers mentioned in In/Out of Scope, populate
`OFFER_BOUNDARIES.md` with use case boundary maps and Decision Log entries. Boundary
work is a full-scope activity — it may require modifying `Use_Cases.csv` (scope
corrections, ownership notes), this Hypothesis (scope tables), and files in related
offers (bidirectional sync). Editing use cases during boundary work is expected,
not a violation of any rule.
6. 01_BS/02_Market_Technology_Scanning.md — + Proof & Validation Strategy (PoT/PoC focus)
7. 01_BS/03_Strategic_Alignment.md ← /strategy + /qa-strategy gate
Expanded: Portfolio Fit & Cannibalization, Regulatory & Compliance Feasibility,
Delivery Strategy, full Channel-Alliance (Partner) Strategy.
8. 01_BS/05_Vendor_Partner_Management.md ← /strategy + /qa-strategy gate
Co-output of Step 7. Vendor/partner tracker: shortlisted vendors, partner types,
commercial terms, integration requirements.
9. 01_BS/04_Market_Opportunity_Assessment.md — + Demand Signal Validation (CRM, RFP,
inbound/outbound, partner evidence), PEST, TAM/SAM/SOM
10. 01_Business_Strategy.md ← Summary of 01_BS/
11. IDEATION_DECK.md → .pptx ← delegate to /ideation-deck
--- RFE (Ready for Engagement) ---
Offer Hypothesis 2-pass model: Step 1 produces a DRAFT hypothesis to guide research. Step 5 COMPLETES the hypothesis after research and use cases provide evidence. This avoids premature commitment while ensuring research is directional.
12. POT.md (optional) ← delegate to /pot + /qa-pot gate
Enriched: Exit & Reversibility, Lifecycle, Integration Risk Scorecard,
Risk Register, Migration & Coexistence, Economic Comparison (mandatory).
13. POC.md (optional, after POT) ← delegate to /poc + /qa-poc gate
Success criteria, partner/customer selection, execution plan, results & evidence,
commercial & delivery validation, feedback integration, Go/No-Go decision.
14. 02_OS/01_Target_Segments_Use_Cases.md — + Adoption & Change, Industry Vertical lens
15. 02_OS/02_Messaging_Differentiation.md — + Value Realization Model
16. 02_OS/03_Offering_Taxonomy_Roadmap.md ← /catalogue + /qa-catalogue gate
+ Delivery & Ops Readiness Assumptions, Success Criteria & Exit Conditions
+ §5.4 Capability & Dependency Assessment (4P): People/Process/Platform/Partner
tables + Scale Gates → pre-cooks LEAN_BUSINESS_CASE.md §8.3
17. 02_Offering_Strategy.md ← Summary of 02_OS/
18. FINANCIAL_MODEL_DRAFT.md (OPTIONAL) ← /qa-financial gate
Recommended for complex financial models. Pre-cooks LEAN_BUSINESS_CASE.md §4 + §12.
Content: pricing per SKU, ARPU by segment, Cost-to-Serve, FTE by year,
investment phasing (Explore/Pilot/Scale), 3-year projection, TCO/ROI,
deal profile, assumptions by category.
If exists at Step 24 → primary source for LBC §4 full + §12, no re-derivation.
19. SOLUTION_DESIGN.md - Draft ← delegate to /service
Architecture: HLD/LLD, reference architecture, integration blueprints,
platform dependencies, validated solution packages.
20. SERVICE_DESIGN.md - Draft ← delegate to /service + /qa-sd gate
TMF decomposition: CFS → RFS → Resources, order fulfillment.
21. OFFER_DESCRIPTION.md - Draft ← delegate to /service + /qa-od gate
22. RISK_REGISTER.md (OPTIONAL) ← no QA gate (validated informally)
Recommended for complex or high-risk offerings. Pre-cooks LEAN_BUSINESS_CASE.md §9.1.
N risks (no limit), each with: Category / Impact / Likelihood / Overall Risk /
Root Cause / Leading Indicators / Kill-Pause Criteria / Decision Owner.
Risk IDs: RISK-XXX. Updatable iteratively throughout Formulation Phase.
If exists at Step 24 → direct source for LBC §9.1 risk cards, no reinvention.
23. OPERATIONAL_PLAYBOOK.md - Draft ← delegate to /service + /qa-sd gate
Draft produced before Business Case — provides BC §8.2 (Delivery Readiness)
and §8.3 (4P Capability) with operational evidence.
24. LEAN_BUSINESS_CASE.md - Draft ← /qa-financial + /qa-consistency gates
Format rules: §8.3 uses 5-subsection 4P format (source: OS/03 §5.4);
§9.1 uses N-risk card format (#### Risk N, 8 sub-fields, no limit);
§10.5 Decision Framework (Continue/Adjust/Kill table).
§5.7 + §5.8 + §8.1 are lean hypotheses pointing to post-BC steps.
25. LEAN_BUSINESS_CASE.pptx - Final (optional) ← delegate to /bc-to-pptx + /qa-pptx gate
Branded PPTX deck generated from approved LEAN_BUSINESS_CASE.md.
--- RF-Enablement (Ready for Enablement) ---
26. SOLUTION_DESIGN.md - Final ← delegate to /service (polish from Step 19)
27. SERVICE_DESIGN.md - Final ← delegate to /service + /qa-sd gate
28. OPERATIONAL_PLAYBOOK.md - Final ← delegate to /service
Expanded: Customer Transition & Go-Live (pre-go-live checklist, cutover,
hypercare, knowledge transfer, welcome pack).
29. OFFER_DESCRIPTION.md - Final ← delegate to /service + /qa-od gate
30. PRE_SALE_ENABLEMENT.md → .pptx ← delegate to /enablement + /qa-enablement
Presales audience: technical selling, demos, solution positioning,
certification paths, capacity model, TCO/ROI.
31. SALES_ENABLEMENT_PLAYBOOK.md → .pptx ← delegate to /enablement + /qa-enablement
Commercial audience: sales playbook, capability maps, training, investment.
32. OPS_ENABLEMENT.md → .pptx ← delegate to /enablement + /qa-enablement
Operations audience: delivery runbooks, operational training, tooling,
SLA framework, Day-2 support model, org capability & capacity.
33. DISCOVERY_QUESTIONNAIRE.md ← delegate to /enablement
Qualification & discovery questionnaire by segment.
34. BATTLECARD.md ← delegate to /enablement
35. ONE_PAGER.md ← delegate to /enablement
36. DATASHEET.md ← delegate to /datasheet
37. CPQ_CALCULATOR.xlsx ← delegate to /cpq
38. COMMERCIAL_PLAYBOOK.md ← delegate to /commercial-playbook
Rate cards, billing, partner economics. BC §5.7 = summary referencing this doc.
--- RFS (Ready for Sale) + RFD (Ready for Delivery) --- --- RFB (Ready for Business) = Offer Launch ---
OFFER_BOUNDARIES.md with use case IDs and a timestamp. Never write a boundary decision inline only — always log it in the registry too. After logging, the check_boundary_sync.py hook will remind you to update the related offer's registry from the other side.OFFER_BOUNDARIES.md. It includes: analyzing use cases across offers, understanding decisions and their cascading effects, and modifying whatever files are necessary — including Use_Cases.csv, 01_Offer_Hypothesis.md scope tables, and any other affected document. The registry records the decisions; the decisions themselves cascade into corrections across multiple files. Editing use cases during boundary work is expected, not a violation.When a document defines a classification (e.g., hardware tiers, use case list), it becomes the AUTHORITATIVE SOURCE. All other documents MUST reference it, not restate with potentially different values.
| Data Point | Authoritative Source | Referenced By |
|---|---|---|
| Hardware tiers/specs | 00_Research/technical.md | All BS, OS, BC docs |
| Use case count/list | Use Cases.csv + 01_BS/01_Offer_Hypothesis.md | BS, OS, OD, BC docs |
| Gap IDs and status | GAPS.md | All research files |
| Segment list | 01_BS/01_Offer_Hypothesis.md | All downstream docs |
| Use case ratings per stack | POT.md § Use Case Capability Assessment (TOTAL row) | 02_OS/01_Target_Segments, 03_Taxonomy, SD, OD, BC |
| Platform stack decision | POT.md § Decisions (D-POT-XXX) | All OS, SD, OD, BC docs |
| SKU definitions | 02_OS/03_Offering_Taxonomy_Roadmap.md | SD, OD, BC docs |
| Channel & Partner Economics (detail) | COMMERCIAL_PLAYBOOK.md §5 | BC §5.7 = summary referencing COMMERCIAL_PLAYBOOK.md |
| Pricing/ARPU | LEAN_BUSINESS_CASE.md | None (final synthesis) |
Rule: When writing a count or classification, always cite the authoritative source: "[N] use cases (per Use Cases.csv)" — never hardcode a number without citing where it is defined.
Deliverables: All pipeline step documents per 00_Prompts/pipeline.md (38 steps across 3 phases)
Validation: Per-step QA gates (see QA Gates table below)
Acceptance Criteria:
[INCOMPLETE TRACE] markers remaining[TBD] without GAP-XXX reference in GAPS.mdBefore presenting ANY document for approval, scan for:
[INCOMPLETE TRACE] markers — MUST be resolved before presenting[TBD] markers — document and justify each remaining TBDMay invoke for specific tasks:
| Agent | Steps | Responsibility |
|---|---|---|
/kickoff | 2 | Web research → populate 00_Research/*.md files |
/research | 3 | Process input/ PDFs and reports into research files |
/use-case-research | 4 | JTBD synthesis, segment heat map, Use_Cases.csv |
/strategy | 7, 8 | Strategic alignment, corporate goals, ABC OKRs, vendor management |
/customer | — | Segment/persona clarification (on demand) |
/catalogue | 16 | Offering taxonomy, Unified Catalogue compliance |
/ideation-deck | 11 | Ideation Deck for internal board pitch |
/pot | 12 | Proof of Technology evaluation (technology stack comparison) |
/poc | 13 | Proof of Concept execution and Go/No-Go |
/service | 19-21, 23, 26-29 | SOLUTION_DESIGN + SERVICE_DESIGN + OP + OD (Draft + Final) |
/enablement | 30-35 | PRE_SALE + SALES + OPS Enablement + DQ + Battlecard + One Pager |
/datasheet | 36 | Customer-facing technical datasheet |
/cpq | 37 | CPQ Calculator (pricing tool) |
/commercial-playbook | 38 | Commercial Playbook (rate cards, billing, partner economics) |
/bc-to-pptx | 25 | PPTX deck generation from approved LEAN_BUSINESS_CASE.md |
After completing each pipeline step, update PROGRESS.md:
mcp__hindsight__retain to store a structured summary: what went well, what caused rework, key decisions, transferable patterns. Tag with offering ID + milestone name.When to update: After each approval gate, after QA runs, and after any user decision that affects the offering's direction.
| Checkpoint | QA Agent | What to Validate |
|---|---|---|
| After Step 2 (kickoff research) | /qa-research | Data attribution, source consistency |
| After Step 3 (input processing) | /qa-research | Data attribution, source consistency |
| After Step 4 (use cases) | /qa-use-cases | CSV format, JTBD quality, agnostic language, coverage |
After Step 7 (03_Strategic_Alignment.md) | /qa-strategy | ABC Goals, CIT OKRs, value proposition alignment |
After Step 12 (POT.md, if created) | /qa-pot | Rating coverage, economic separation, source traceability, decision format |
After Step 13 (POC.md, if created) | /qa-poc | Success criteria, evidence, Go/No-Go justification |
After Step 16 (03_Offering_Taxonomy_Roadmap.md) | /qa-catalogue | 3-Table Model, Delivery Types, SKU taxonomy |
After Step 20 (SERVICE_DESIGN.md draft) | /qa-sd | TMF decomposition, CMDB, fulfillment |
After Step 21 (OFFER_DESCRIPTION.md draft) | /qa-od | Completeness, TMF compliance, structure |
After Step 24 (LEAN_BUSINESS_CASE.md) | /qa-financial | ARPU, margins, forecasts, TCO/ROI, investment phasing, assumptions |
After Step 24 (LEAN_BUSINESS_CASE.md) | /qa-consistency | Cross-document consistency, Exec Summary alignment, 3 Kill Gate decisions |
After Step 25 (LEAN_BUSINESS_CASE.pptx) | /qa-pptx | PPTX slide content and visual quality |
After Step 27 (SERVICE_DESIGN.md final) | /qa-sd | SD-OD alignment, TMF compliance |
After Step 29 (OFFER_DESCRIPTION.md final) | /qa-od | Completeness, structure, TMF compliance |
| After Steps 30-32 (enablement docs) | /qa-enablement | Completeness, accuracy, alignment with offering strategy |
QA Handoff Format:
/qa-strategy OFFER-XXX - Validate 03_Strategic_Alignment.md
Task summary: [what was done]
Files modified: [list]
Key decisions: [list]
If QA returns ISSUES FOUND: Fix listed issues and re-call the QA agent (max 2 rework cycles per Contract). If same issue recurs or max cycles reached, escalate to user. When delegating to sub-agents (e.g., /service, /research), the sub-agent handles its own reflection loop — do NOT add an additional retry around the delegation.
1. ARPU Validation
2. Assumptions Validation
3. Forecast Validation
4. New Subsections (§4.11-4.13)
5. Kill Gates
6. Source Citations
## Development Progress - OFFER-XXX
### Current File
Processing: [folder]/[file] (Step [N] — [Phase])
### Context Loaded
- analysis.md
- [relevant module]
- [source documents]
### Proposed Content
[content for approval]
### Gaps Identified
- [any new gaps to add to GAPS.md]
### Milestone Status
- [ ] RFE (after Step 11)
- [ ] RF-Enablement (after Step 24)
- [ ] RFS (commercial readiness)
- [ ] RFD (technical/ops readiness)
- [ ] RFB (offer launch)
### QA Status
- [ ] /qa-research (pending — after Steps 2, 3)
- [ ] /qa-use-cases (pending — after Step 4)
- [ ] /qa-strategy (pending — after Step 7)
- [ ] /qa-pot (pending — after Step 12, if applicable)
- [ ] /qa-poc (pending — after Step 13, if applicable)
- [ ] /qa-catalogue (pending — after Step 16)
- [ ] /qa-sd (pending — after Steps 20, 27)
- [ ] /qa-od (pending — after Steps 21, 29)
- [ ] /qa-financial (pending — after Step 24)
- [ ] /qa-consistency (pending — after Step 24)
- [ ] /qa-enablement (pending — after Steps 30, 31, 32)
- [ ] /qa-pptx (pending — after Step 25 deck generation)
$ARGUMENTS
Mine architecture decision records (ADRs), gotcha files, runbooks, and docs/archive for cross-project lessons that warrant ai-playbook canonical specs. Use when a project lacks a populated retros/ directory but has equivalent material in other forms.
Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
Orchestrate the canonical task↔PR↔release flow end-to-end. Two modes — `/dev-flow start <description>` scaffolds an OpenSpec change + branch + (optional) worktree + git hook ready for commits; `/dev-flow ship` validates the current branch + pushes + opens PR + monitors CI. Use whenever you start any non-trivial change in a playbook-consuming project. LLM-agnostic — works for Claude Code, Cursor, Antigravity, Gemini CLI, OpenCode, and humans.
Implement an OpenSpec change in parallel using multiple subagents (one per disjoint task group inside the same slice). Use when the slice's tasks.md has ≥2 task groups with disjoint write-paths AND >30 min of parallelisable work. For sequential implementation use openspec-apply-change instead.
Review code changes adversarially using parallel review layers (Blind Hunter, Edge Case Hunter, Acceptance Auditor) with structured triage into actionable categories. Use when the user says "run code review" or "review this code"