菜单
Use when writing an end-to-end SaaS implementation methodology across control plane, application plane, tenant isolation, observability, billing, onboarding, cutover, and adoption; use the combined AI-on-SaaS methodology when AI features are in scope.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/peterbamuhigire/proposal-skills --skill saas-implementation-methodology命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Use when a SaaS bid needs buyer qualification through ICP fit, critical event, pain chain, role-level impact, decision process, and no-bid signals; use AI-on-SaaS discovery when AI data, model, or hallucination questions apply.
Use when a SaaS proposal needs a time-boxed POC or pilot with explicit scope, success measures, exit criteria, and a decision gate to implementation; use the AI-on-SaaS pilot skill when evaluation datasets or hallucination controls apply.
Use when routing, drafting, reviewing, or assembling a complete consulting proposal, EoI, bid, or tender response; use a numbered pipeline skill when only one known section is required.
基于 SOC 职业分类
正在显示 SKILL.md
| name | saas-implementation-methodology |
| description | Use when writing an end-to-end SaaS implementation methodology across control plane, application plane, tenant isolation, observability, billing, onboarding, cutover, and adoption; use the combined AI-on-SaaS methodology when AI features are in scope. |
| metadata | {"portable":true,"compatible_with":["claude-code","codex"]} |
Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.
06-methodology/ directly).| Artefact or fact | Required? | Source/provider | If absent |
|---|---|---|---|
| ToR / RFP and any architectural context. | Required | Buyer, ToR, approved records, or discovery | Mark unavailable, request it, and qualify any affected claim or artefact. |
| The buyer's vertical and regulatory situation. | Required | Buyer, ToR, approved records, or discovery | Mark unavailable, request it, and qualify any affected claim or artefact. |
| Discovery outputs (pain chain, ICP, Critical Event, decision process). | Conditional | Buyer, ToR, approved records, or discovery | Mark unavailable, request it, and qualify any affected claim or artefact. |
| The integration environment (core systems, identity, payments, regulator reporting). | Conditional | Buyer, ToR, approved records, or discovery | Mark unavailable, request it, and qualify any affected claim or artefact. |
| Tenant-model expectations (number of tenants, variation across tenants, isolation expectations). | Conditional | Buyer, ToR, approved records, or discovery | Mark unavailable, request it, and qualify any affected claim or artefact. |
| Engagement length and any phasing constraints. | Conditional | Buyer, ToR, approved records, or discovery | Mark unavailable, request it, and qualify any affected claim or artefact. |
saas-risk-register-for-proposals.md.Stop condition: Stop before asserting scope, compliance, value, acceptance, or readiness when a load-bearing input is missing or contradicted.
Recovery: Record the gap, owner, and next evidence step; then return the narrowest qualified proposal content that remains supportable.
| Artefact | Consumer | Observable acceptance condition |
|---|---|---|
| Methodology section for SaaS implementation engagements. | Proposal evaluator, buyer owner, and delivery team | Content is complete, traceable to named inputs, and usable in its stated proposal section without an unsupported claim. |
| Deliverables Summary table. | Proposal evaluator, buyer owner, and delivery team | Content is complete, traceable to named inputs, and usable in its stated proposal section without an unsupported claim. |
| Standard Phases with P-I-P pattern applied. | Proposal evaluator, buyer owner, and delivery team | Content is complete, traceable to named inputs, and usable in its stated proposal section without an unsupported claim. |
| Cross-links to architecture credibility block, trust and compliance section, customer success package, lifecycle communications, and risk register. | Proposal evaluator, buyer owner, and delivery team | Content is complete, traceable to named inputs, and usable in its stated proposal section without an unsupported claim. |
When the engagement delivers AI features inside the SaaS product (RAG, copilots, agents, AI analytics, AI-assisted decisioning), use ../ai-on-saas-combined-methodology/SKILL.md instead of this skill, or layer it on top. The AI overlay introduces a third plane (the AI plane: model gateway, model registry, eval harness, RAG indexes per tenant, red-team harness, drift watch) alongside the control and application planes; introduces AI workstreams in every phase (golden-dataset + threshold spec in Phase 1; model gateway + eval CI in Phase 2; AI feature build with abstain logic in Phase 3; red-team + hallucination SLO in Phase 4; AI eval acceptance gate in Phase 5; drift watch in Phase 6; quarterly red-team and eval refresh in Phase 7); and introduces AI-specific acceptance criteria (golden-set pass, hallucination ceiling, abstain-correctness, cost-per-call, tenant-isolation probe pass). See also ../references/ai-on-saas-methodology-blocks.md.
| Evidence | Consumer | Acceptance condition |
|---|---|---|
| Input-and-assumption record | Proposal lead and reviewer | Every load-bearing claim maps to a source, approved assumption, or explicit gap. |
| Decision and review record | Buyer owner and delivery lead | The selected option, rationale, owner, stop condition, and approval status are visible. |
| Section acceptance check | Evaluator-readiness reviewer | Each output meets its stated acceptance condition and unresolved checks are not presented as passed. |
This skill may read supplied tender, discovery, architecture, commercial, security, and operating evidence and draft proposal artefacts within the authorised workspace. It must not publish, send, certify compliance, accept contractual terms, change production systems, spend funds, or disclose confidential evidence without explicit authority. Review and analysis remain read-only by default.
If files, current legal or technical evidence, calculation tools, network access, or reviewers are unavailable, produce the narrowest useful qualified draft. Label assumptions and checks as not assessed, omit unsupported assurances or figures, and state the exact evidence and owner needed to complete the work. An unavailable check never becomes a pass.
| Choice | Action | Failure or risk avoided |
|---|---|---|
| Tenant architecture choice | Record isolation, context, data, observability, and cutover decisions before estimating | Non-credible plan or unsafe multi-tenancy |
| Missing load-bearing evidence | Stop the affected claim, record the gap and owner, and continue only with separable supported content. | Fabricated assurance or hidden dependency |
| Conflicting buyer and supplier evidence | Surface the conflict for decision; do not silently choose the favourable version. | Misaligned scope, price, or acceptance |
| Irreversible, contractual, publishing, or production action | Obtain explicit authority and preserve an approval record before acting. | Unauthorised commitment or mutation |
Where source-system data quality is unknown, place profiling and remediation before migration rehearsal; do not promise cutover until reconciliation, UAT, rollback, and owner approvals are evidenced.