delivery-bootstrap

Delivery Bootstrap Skill

Just-in-Time tech stack detection and setup.

Workflow

1. Check product_type from .claude/diamonds/active.yml:
2. If product_type is set (from /mycelium:interview), use it to determine the delivery profile.
3. If not set, scan for indicators per ${CLAUDE_PLUGIN_ROOT}/jit-tooling/detector.md Step 1b:
4. Curriculum/lesson plans, LMS config -> content_course
5. Manuscript/chapters, editorial calendar -> content_publication
6. Video scripts, subtitle files, podcast RSS -> content_media
7. Prompt templates, model configs, agent definitions -> ai_tool
8. Service blueprints, pricing docs -> service_offering
9. If non-software product_type detected: skip software tooling detection (Steps 2-3 below), configure product-type-appropriate validation instead, and proceed to Step 4.

1b. Scan project root for technology indicators (software and ai_tool with code):

• Package files: package.json, Cargo.toml, go.mod, requirements.txt, pyproject.toml, Gemfile, pom.xml, build.gradle
• Config files: tsconfig.json, .eslintrc, .prettierrc, rustfmt.toml, .editorconfig
• CI/CD: .github/workflows, .gitlab-ci.yml, Jenkinsfile, Dockerfile
• Framework indicators: next.config.js, nuxt.config.ts, angular.json, etc.

1. Identify stack components (software/ai_tool with code):
2. Language(s) and version(s)
3. Framework(s)
4. Package manager
5. Test runner and framework
6. Linter and formatter
7. Build tool
8. CI/CD platform
9. Database (if detectable)
10. Deployment target

1. Verify tooling works:
2. Run build command
3. Run test command
4. Run lint command
5. Note any failures or warnings

3a. Offer the feedback-loop tooling menu (OFFER-MENU layer):

• For the detected stack, present the best-practice menu from ${CLAUDE_PLUGIN_ROOT}/jit-tooling/security-scanning.md (SAST, dep audit, secrets, test runner, linter), ordered smallest-friction first (typically: secrets scan → linter → SAST → dep audit → container scan).
• Frame as: "Best practice is to have tools help you shorten the feedback loop. For your detected stack ({lang}), the menu is: {list}. Want help finding and configuring any of these?"
• Never auto-install. Never pick rulesets on the user's behalf. Adoption is per-tool, per-consent. The user owns the choice. See feedback-jit-nudge-not-push (founder principle, 2026-05-26).
• If user declines or defers, record the offer in active-stack.yml under tooling_offers_declined with timestamp — later shape-triggers (Step 3b) can re-surface the relevant subset.

3b. Risk-shape re-offer (RISK-TRIGGERED layer):

• Scan code for risk-shape patterns. If any fires AND the corresponding tool was declined in 3a, re-offer the relevant subset with the risk as citation. Patterns:
• AUTH shape: /login, /auth, /register, password, session, token, jwt, oauth, x-user-id and similar trust-bearing headers → re-offer SAST + suggest /mycelium:threat-model and /mycelium:security-review. SAST blind spot: identity-trust design (e.g., x-user-id header trusted as auth) is NOT catchable by SAST tools — they don't model intent. Route to /mycelium:security-review regardless of whether SAST consent was given.
• AI shape: imports from ai_components categories per detector.md Step 1c → suggest /mycelium:xai-check
• PII / data shape: email, ssn, phone, address, payment, card, schema fields matching PII patterns → suggest /mycelium:privacy-check + secrets scanner
• Public endpoint shape: routes without auth middleware → suggest SAST + DAST. SAST blind spot: "no authorization check" is design-level; SAST can flag suspicious patterns but cannot confirm absence-of-intent. Route to /mycelium:security-review.
• File-upload shape: upload, multipart, FormFile, ServeFile, ServeContent, Content-Disposition, file-system write from request → re-offer SAST + suggest /mycelium:threat-model with explicit MIME-allowlist + filename-sanitization + size-cap + overwrite-policy review. SAST partial coverage: gosec/semgrep catch path-traversal (filepath.Join without Base), but cannot catch design flaws (MIME confusion via stored files, public-list disclosure, missing auth).
• Cite the trigger explicitly per CLAUDE.md attribution rule: (per: AUTH shape detected at app.py:42 → SAST recommended).
• The 4-layer composition (OFFER-MENU + RISK-TRIGGERED + NUDGE-AT-FAILURE + PR-TIME) is derived from a deep-study comparison of 10 adoption approaches (2026-05-26). Strongest single-finding: contextual nudges at decision moments produce ~8× higher detection vs no-nudge baseline (Less is More, arxiv 2202.04586; consistency_only — single experimental study). Other layers live in /mycelium:security-review, /mycelium:threat-model, /mycelium:reflexion (NUDGE-AT-FAILURE) and /mycelium:definition-of-done (PR-TIME).

1. Document existing patterns:
2. Code organization (monorepo, src layout, etc.)
3. Naming conventions
4. Test patterns
5. Error handling patterns
6. API patterns

1. Scaffold Architecture Decision Records (if applicable):
2. Check: Does the project have significant architecture decisions ahead? Indicators:
3. Multiple competing implementation approaches (e.g., REST vs GraphQL, monolith vs microservices)
4. New infrastructure choices (database, hosting, auth provider)
5. Framework selection or migration
6. Integration with external systems
7. If yes: create docs/adr/ directory and a template file docs/adr/0000-template.md:

``` # [NUMBER]. [TITLE]

Date: [DATE]

## Status Proposed | Accepted | Deprecated | Superseded by [ADR-XXXX]

## Context What is the issue that we're seeing that is motivating this decision?

## Decision What is the change that we're proposing and/or doing?

## Consequences What becomes easier or more difficult to do because of this change? ```

• If no significant architecture decisions are foreseeable: skip. Don't scaffold ceremony for a weekend project.
• ADR format: Nygard (Context/Decision/Consequences). Lightweight by design — each ADR should be readable in under 2 minutes.

1. Output:

``` ## Stack Profile

• Language: [x] v[y]
• Framework: [x]
• Package manager: [x]
• Test: [command] ([framework])
• Lint: [command]
• Build: [command]
• CI/CD: [platform]

## Commands

• Install: [command]
• Dev server: [command]
• Test: [command]
• Build: [command]
• Lint: [command]

## Observed Patterns

• [list of patterns detected]

## Issues Found

• [any broken tooling or warnings]

## Architecture Decision Records

• Scaffolded: yes/no
• Location: docs/adr/
• Pending decisions: [list if any identified during bootstrap]

## Risk Shapes Detected

• [list of risk shapes fired in Step 3b, with citations]

## Recommended Next Skills

• [if AUTH / public-endpoint / file-upload / PII shape fired] → run /mycelium:security-review before merging (per: SAST blind spot — identity/authorization/business-logic flaws aren't tool-catchable)
• [if AI shape fired] → run /mycelium:xai-check
• [if PII shape fired] → run /mycelium:privacy-check

```

Rules

• Use the project's established patterns. Don't impose external preferences.
• Be language-agnostic in principles, language-specific in implementation.
• If tooling is broken, flag it rather than silently working around it.

Canvas Output

Create/update ${CLAUDE_PLUGIN_ROOT}/jit-tooling/active-stack.yml with detected stack configuration. See ${CLAUDE_PLUGIN_ROOT}/jit-tooling/active-stack.example.yml for the expected format.

Theory Citations

• Forsgren: Accelerate (tooling and automation)
• Smart: Sooner Safer Happier (remove friction)
• Nygard: Architecture Decision Records (lightweig