Skill Shack Submitter Preflight

Submitted by Heather Lux ({{USER_EMAIL}}).

Use this skill when a user wants to submit one of their local Scout skills to Skill Shack and needs the package cleaned, scrubbed, validated, and converted into a review-ready submission packet before it reaches the Skill Shack gatekeeper. Triggers include: "submit this skill to Skill Shack", "package my skill for Skill Shack", "preflight this skill submission", "make this Skill Shack ready", "check my skill before submitting", or "sanitize this skill for sharing".

This is the submitter-side companion to Skill Shack review and publishing. It does not publish, approve, deploy, or announce a skill. Its job is to reduce cleanup for the reviewer by catching obvious problems before submission.

What this skill does

Skill Shack Submitter Preflight inspects a local skill folder, separates share-safe prompt content from private/runtime content, drafts a clean review packet, and stops for explicit approval before anything leaves the user's machine.

It produces:

• A target skill summary.
• A share-safe prompt body or hardened draft.
• Included/excluded file lists.
• A scrub report for private data, secrets, local paths, customer names, tenant IDs, and runtime artifacts.
• A dependency routing recommendation: SharePoint shared asset vs first-run onboarding-build.
• A first-run onboarding block when personalization is needed.
• A review packet ready for Skill Shack triage.
• An optional ZIP only when the user explicitly needs one for local review.

First-run onboarding

On first run, ask these questions and save the answers in a local per-skill profile, such as skill-shack-submitter-preflight-profile.json:

1. Where are your local Scout skills stored?
2. Where should preflight staging files be written?
3. What submission endpoint or process should be used after approval?
4. What identity should be used for attribution: name, email, team, and optional contributor notes?
5. Should customer/account names be allowed in drafts for local review, or always replaced with placeholders immediately?
6. Should the skill create a ZIP package by default, or only produce markdown review packets?

Never hardcode the user's local paths, identity, or submission endpoint in the published prompt.

Required workflow

1. Identify the target skill

Ask for the local skill folder or skill name. Confirm:

• Skill name and suggested slug.
• Submitter attribution.
• Intended audience.
• Category suggestion.
• Trigger phrase.
• What problem it solves.
• Expected output.
• Tools/data sources used.
• Actions it may take.

If the skill folder cannot be found, stop and ask for the correct path. Do not guess.

2. Inventory files

List files in the target skill folder and classify each file:

• Prompt body: SKILL.md, README, usage instructions, examples that are safe to share.
• Static shared dependency: templates, sample files, reference data, fixed lookup tables, images, docs, or brand assets that are byte-identical for every authorized user.
• User-specific/runtime file: profiles, cache files, logs, generated outputs, auth state, browser profiles, local paths, customer/account extracts, tenant IDs, subscriptions, tokens, secrets, screenshots with private data, or anything generated from the submitter's environment.
• Unknown: anything the skill cannot confidently classify.

Default unknown files to excluded until the user confirms they are share-safe.

3. Scrub and harden

Scan all candidate share files for:

• Names and emails.
• Local paths.
• Customer/account names.
• Tenant IDs, subscription IDs, TPIDs, opportunity IDs, and other business identifiers.
• Tokens, secrets, API keys, cookies, bearer strings, connection strings, and passwords.
• Private calendar/email/Teams/file excerpts.
• Internal-only URLs that should be user-provided in onboarding instead of hardcoded.

Replace hardcoded personal values with placeholders or first-run onboarding questions. Do not silently remove required behavior; preserve the intent and make personalization explicit.

4. Dependency routing

For every extra dependency, apply this rule:

Would this file be byte-identical for every user?

• Yes: route to SharePoint/shared asset path and describe how the publisher should upload or link it.
• No: route to onboarding-build and convert the dependency into a first-run setup question or generated local file.
• Mixed: split it. Never publish user-specific files to SharePoint, and never force static shared references through onboarding when a shared library link is cleaner.

5. Add or verify first-run onboarding

If the skill includes any personalized data, local paths, user-specific IDs, customer/account names, or configurable source locations, inject a first-run onboarding block.

The onboarding block should:

• Ask for only the values needed.
• Save answers to a local per-skill profile file.
• Explain where generated files are stored.
• Fail clearly when required access or setup is missing.

A skill can skip onboarding only when it is genuinely generic and has no user-specific state.

6. Write-action safeguards

If the submitted skill sends email or Teams messages, shares files, updates CRM/MSX, deletes/modifies data, uploads files, creates calendar events, or performs any visible outbound/write action, add a hard preview-and-confirm rule:

• Show who receives or is affected.
• Show exact content or object changes.
• Warn when private user data is included.
• Wait for explicit confirmation before acting.

7. Produce the review packet

Return a concise packet with:

• Display title.
• Suggested slug.
• Submitter attribution.
• Category suggestion.
• Trigger phrase.
• One-sentence "does" summary.
• Expected output.
• Data/tools used.
• Actions it might take.
• Scrub report.
• Dependency routing table.
• Onboarding status.
• Publish-readiness recommendation.
• Hardened prompt body.

If creating a ZIP, include only share-safe files and include a manifest that lists excluded files and why they were excluded.

8. Approval gate

Before submitting, uploading, emailing, Teams-sending, or posting anything outside the user's machine, show:

• The destination.
• The exact files or text that will be submitted.
• The scrub findings.
• Any unresolved risks.

Wait for explicit user approval. If approval is not given, leave the staged packet local and do not submit.

Output format

Return:

SUBMISSION PREFLIGHT: <skill name>
Does       : <one sentence>
Slug       : <suggested-slug>
Attribution: <name/email/team>
Scrub      : <clean | needs-scrub: ...>
Deps       : <none | SharePoint: ... | Onboarding-build: ... | mixed: ...>
Onboard    : <present | inserted | missing/blocking | not needed>
Package    : <review packet path and optional ZIP path>
Submit     : <ready after approval | blocked: reason>

Keep the result focused on the cleanup decisions the reviewer needs. Do not bury the gatekeeper in raw file dumps.

Safety rules

• Never publish or submit secrets.
• Never include runtime auth state, browser profiles, local cache folders, logs, generated customer outputs, or private M365 excerpts in a shared package.
• Never delete or modify the original source skill folder.
• Never send the packet or ZIP externally without explicit approval.
• Preserve submitter attribution in the packet.
• Prefer a hardened markdown prompt over a ZIP when the ZIP would include unnecessary or risky files.

Relationship to other Skill Shack skills

• Use this skill before the user submits a skill to Skill Shack.
• Use Skill Shack review/gatekeeper workflows after a submission has arrived in the queue.
• Use Skill Shack upload/publishing workflows only after a skill has been approved for publication.