Add a reviewable project-incubation bootstrap pack skill

[szmyty]

Outcome

Add a provider-neutral Aether skill and versioned output contract that turns a reviewed project brain-dump / Mindgarden knowledge set into a coherent project-incubation bootstrap pack before implementation begins.

This is a composition layer between free-form idea capture and repository execution. It should help a person move from “I have a durable idea and a lot of connected thoughts” to a reviewable, portable project foundation without forcing every immature idea into code or GitHub issues.

Why this is distinct

Existing work already owns adjacent concerns:

• aether#78 — free-form brain-dump triage and deduplicated GitHub backlog promotion;
• mindgarden#39 — architecture skeleton for specs, schemas, templates, skills, and garden outputs;
• mindgarden#13 / #14 — reviewable gardenization and routing;
• aether#5 — foundational architecture-document skills;
• sanctuary#10 — reusable repository-foundation ownership boundaries;
• egohygiene/egohygiene#428 — later extraction of a proven reusable repository template.

The missing layer is a cohesive project-level bootstrap artifact that composes those capabilities and preserves the relationships among vision, architecture, data contracts, runtime components, governance questions, and execution backlog.

Intended workflow

free-form project brain dump
        ↓
normalized + reviewed knowledge
        ↓
project-incubation bootstrap plan
        ↓
reviewed bootstrap pack
        ├─ project vision / purpose
        ├─ creative or product pillars
        ├─ glossary / canonical concepts
        ├─ system + architecture map
        ├─ spec inventory
        ├─ schema / data-contract inventory
        ├─ component / subsystem inventory
        ├─ decision / ADR candidates
        ├─ project-governance prompts
        ├─ experiments / unknowns
        └─ dependency-aware backlog candidates
        ↓
optional repository materialization + issue promotion

The bootstrap pack is a planning artifact, not permission to create repositories, publish private ideas, sign agreements, or implement code automatically.

Spec → schema → component development profile

Capture an explicit reusable development model for projects where these layers are useful:

• specs define intent, behavior, constraints, and acceptance criteria;
• schemas define durable data shapes, contracts, and interoperability boundaries;
• components/subsystems define runtime composition and implementation ownership;
• systems/orchestrators coordinate components without becoming monolithic god objects;
• implementation remains replaceable beneath the accepted contracts.

The skill should identify where one of these layers is unnecessary rather than generating decorative files by default.

Bootstrap-pack contract

Define a versioned machine-readable manifest plus human-readable projections containing at least:

• stable project/bootstrap ID and revision;
• source Mindgarden / archive references and provenance;
• project name or working name, when actually established;
• purpose and intended experience/outcome;
• explicit in-scope and non-goal statements;
• canonical concepts and glossary;
• known constraints and assumptions;
• architecture/system boundaries;
• proposed spec inventory and dependency graph;
• proposed schema/data-contract inventory;
• proposed component/subsystem inventory;
• external platform/runtime dependencies;
• experiments needed to retire uncertainty;
• decisions already made versus ADR candidates;
• unresolved questions;
• project/repository ownership suggestion with evidence;
• private/public and licensing-state placeholders;
• collaborator/governance questions that require explicit human decisions;
• deduplicated GitHub issue candidates or references to existing issues;
• publication/article/visual candidates that are not implementation tasks;
• readiness classification and next recommended bounded action.

Project-governance boundary

The skill may surface questions such as:

• who currently owns the project/IP;
• whether the repository is private or public;
• whether software, creative content, assets, and documentation need different licenses;
• how contributor credit and contribution expectations should be documented;
• whether revenue share, equity, royalties, or assignment agreements may eventually require professional review.

It must not invent legal terms, percentages, ownership transfers, contributor agreements, or tax/entity conclusions. Those remain explicit human decisions and, when consequential, professional-review inputs.

Capture-first behavior

The workflow must preserve exploratory work without prematurely hardening it:

• distinguish ideas from decisions;
• distinguish metaphors/design language from implementation contracts;
• retain competing alternatives when unresolved;
• allow a long-horizon/background project to remain valid without assigning artificial deadlines;
• support “build because I want to use/play/experience it” as a legitimate project purpose;
• keep private creative material private by default.

Output projections

Provide at least:

1. PROJECT-BOOTSTRAP.md — portable human/agent handoff;
2. a machine-readable bootstrap manifest;
3. an architecture/system overview candidate;
4. a spec/schema/component inventory rather than empty generated implementations;
5. an optional backlog-promotion plan compatible with aether#78;
6. an optional content-candidate projection compatible with Mindgarden infographic/publication workflows.

Exact filenames should follow accepted Aether conventions and avoid introducing a conflicting canonical architecture-document hierarchy.

Idempotency and evolution

• Re-running against unchanged reviewed knowledge should reconcile with the existing bootstrap rather than creating parallel contradictory packs.
• Later brain dumps should be able to update, supersede, defer, or reopen parts of the bootstrap explicitly.
• Accepted repository documents and ADRs outrank stale bootstrap suggestions.
• A bootstrap can graduate into repository-owned architecture/specs while remaining preserved as provenance.
• GitHub live state must be rechecked before issue promotion.

Privacy and authority

• Private project ideas remain private by default.
• Public issue/article/visual candidates must be transformed through the selected publication policy rather than copying raw transcript text.
• Personal, health, financial, employment, or unrelated private context must not leak merely because it influenced a project discussion.
• Tool availability does not grant repository creation, publication, legal acceptance, or implementation authority.

Dogfood fixture

Create a synthetic creative-software/game project fixture that begins as a nonlinear brainstorm and contains:

• an experience vision;
• procedural/generative concepts;
• an engine/runtime choice;
• several interacting subsystems;
• a spec/schema/component-driven architecture idea;
• unresolved implementation timing questions;
• collaboration and licensing questions;
• a mixture of engineering tasks and article/visual candidates.

The fixture must use fictional/synthetic names and contain no private user transcript.

Acceptance criteria

• A provider-neutral project-incubation bootstrap skill exists.
• A versioned bootstrap-pack contract/schema exists.
• The skill composes Mindgarden and Aether contracts instead of creating a competing knowledge store.
• Specs, schemas, components, systems, experiments, decisions, and backlog items remain distinct concepts.
• The workflow can omit unnecessary layers instead of generating empty ceremonial files.
• Raw ideas, accepted decisions, unresolved alternatives, and implementation commitments remain distinguishable.
• Project vision and creative/product intent remain traceable to reviewed source evidence.
• Governance/licensing questions are surfaced without fabricating legal conclusions or ownership percentages.
• Private/public publication policy fails closed.
• Re-running unchanged inputs reconciles idempotently.
• Accepted repository evidence supersedes stale bootstrap suggestions.
• Backlog candidates compose aether#78 duplicate search and explicit-write rules.
• Article/visual candidates can remain non-task outputs.
• A synthetic nonlinear project-brainstorm fixture proves brain dump → reviewed knowledge → bootstrap pack → bounded next action.
• Evals cover immature idea, mature project, existing repository, conflicting decisions, private source/public-safe projection, duplicate issues, and denied mutation authority.

Non-goals

• Automatically implementing the project.
• Creating dozens of empty placeholder files solely to look complete.
• Replacing canonical repository architecture documents or ADRs.
• Turning every idea into a GitHub issue.
• Choosing licensing, ownership percentages, revenue splits, equity, or legal agreements for the user.
• Publishing private project concepts by default.
• Replacing Sanctuary repository templates or Mindgarden knowledge contracts.

Related

• Add reviewable brain-dump triage and GitHub backlog promotion skill #78 — brain-dump triage and GitHub backlog promotion
• feat(skills): complete the five foundation-document skill packages #5 — foundational architecture-document skills
• egohygiene/mindgarden#39
• egohygiene/mindgarden#13
• egohygiene/mindgarden#14
• egohygiene/sanctuary#10
• egohygiene/egohygiene#428

Origin

Distilled from a 2026-09-17 dogfood session in which a long-lived creative software/game idea was explored conversationally, then progressively grounded into architecture, specs, schemas, components, repository scaffolding, collaboration questions, and an issue-backed long-horizon development model. The reusable insight is the incubation workflow, not the private project content.