Community/sponsorship configuration and bootstrap instruction improvements (v1.3.0)

.github/FUNDING.yml

@@ -1 +1,7 @@
 github: TechSpokes
+# You can also add other platforms:
+# open_collective: your-collective
+# patreon: your-patreon
+# ko_fi: your-kofi
+# custom:
+#   - 'https://www.techspokes.com'

.intake/README.md

@@ -14,6 +14,8 @@ Place all user-provided source material or skill ideas in this folder.
 
 Agents treat this folder as source material. They infer the intended skill, extract durable knowledge, build `src/SKILL.md`, create references, update documentation, and prepare release packaging.
 
+Agents may create `research/`, `experiments/`, and `playground/` subfolders here to hold evidence gathered while resolving gaps.
+
 Intake files are never release artifacts. They may be transformed into skill references when the content is useful and safe to publish.
 
 When this folder is empty or insufficient, agents should assess what is missing before skill construction. They may resolve gaps by extracting evidence, making low-risk assumptions, inspecting local tools or docs, creating disposable experiments, narrowing scope, asking concise questions, or stopping before build work when construction would require fabrication.

.plans/0000-backlog.md

@@ -14,6 +14,8 @@ All five issues originate from one descendant repository, [skill-postgres-intros
 | [0006](0006-repo-hardening-and-release-process.md) | #6 | Repository hardening, branch protection, release process | in-progress | 2 |
 | [0007](0007-template-feedback-folder.md) | #7 | Scaffold `.skill-template-feedback/` in generated repos | in-progress | 3 |
 | [0008](0008-template-release-process.md) | none | Update the template's own release process and ship v1.2.0 | in-progress | 4 |
+| [0009](0009-community-and-sponsorship.md) | none | Mirror the descendant's community and sponsorship setup | in-progress | 5 |
+| [0010](0010-bootstrap-instruction-improvements.md) | none | Goals-and-values transmission and an alignment-confirmation gate | in-progress | 5 |
 
 ## Progress
 
@@ -23,6 +25,10 @@ Plan 0008 is partially implemented. The branch-and-pull-request flow is document
 
 These remain for the release step and are not yet done: the version bump to `1.2.0` in `package.json` and `docs/VERSION.md`, the `## [v1.2.0]` changelog section, and `docs/releases/v1.2.0.md`.
 
+### Phase 5
+
+Plans 0009 and 0010 are implemented on the `template-community-and-bootstrap` branch and ship together as template v1.3.0. Plan 0009 mirrors the descendant's community and sponsorship setup; its live repository settings were applied with user authorization. Plan 0010 strengthens goals-and-values transmission in the generated `AGENTS.md` and adds an alignment-confirmation step before skill construction.
+
 ## Implementation roadmap
 
 The work lands in four phases on the `template-maintenance-baseline` branch, then ships as a single template release, v1.2.0. Each phase is a coherent commit set that keeps `npm run validate` green.

.plans/0009-community-and-sponsorship.md

@@ -0,0 +1,39 @@
+# 0009: Mirror the descendant's community and sponsorship setup
+
+Issue: none. Requested directly: match the descendant's sponsorship and community settings on the template.
+
+Status: in-progress (implemented on `template-community-and-bootstrap`)
+
+Layer: live repository settings and the `.github/FUNDING.yml` file.
+
+## Problem
+
+The template's community setup diverged from the descendant `skill-postgres-introspection`. The template had Discussions disabled, Projects and Wiki enabled, and a bare `FUNDING.yml`. The descendant had Discussions enabled, Projects and Wiki disabled, and a `FUNDING.yml` with documented platform examples.
+
+## Goal
+
+The template's sponsorship and community configuration matches the descendant, so the template demonstrates the same setup it produces.
+
+## What the descendant has
+
+The descendant's `.github/FUNDING.yml` keeps `github: TechSpokes` and adds commented examples for `open_collective`, `patreon`, `ko_fi`, and a `custom` TechSpokes URL.
+
+The descendant repository has Discussions enabled with the default categories, Projects disabled, and Wiki disabled.
+
+## Steps
+
+Enrich `.github/FUNDING.yml` to match the descendant: keep `github: TechSpokes` and add the commented platform examples.
+
+Apply the live repository settings on `TechSpokes/skill-base-template`: enable Discussions, disable Projects, disable Wiki. These were applied with `gh api repos/TechSpokes/skill-base-template -X PATCH -F has_discussions=true -F has_projects=false -F has_wiki=false`.
+
+## Decisions
+
+The repository settings are outward-facing and were applied with explicit user authorization. The `FUNDING.yml` change is a tracked file and ships in the next release.
+
+Projects and Wiki are disabled to match the descendant's focused setup, not only to enable Discussions. The descendant deliberately keeps both off.
+
+## Verification
+
+Confirm `gh api repos/TechSpokes/skill-base-template` reports `has_discussions` true and `has_projects` and `has_wiki` false.
+
+Confirm `.github/FUNDING.yml` carries the commented platform examples.

.plans/0010-bootstrap-instruction-improvements.md

@@ -0,0 +1,69 @@
+# 0010: Strengthen goals-and-values transmission and add an alignment-confirmation gate
+
+Issue: none. Requested directly after reviewing the descendant's generated agent instructions.
+
+Status: in-progress (implemented on `template-community-and-bootstrap`)
+
+Layer: bootstrap guidance (`.template/bootstrap/*.md`) and the template `AGENTS.md`.
+
+## Problem
+
+Two weaknesses surfaced when comparing the descendant's generated `AGENTS.md` with the bootstrap guidance that should produce it.
+
+First, the descendant's `AGENTS.md` transmits goals and values for local decisions very well. It has a "Core principles the skill must keep" section and an explicit decision stance: surface findings as obstacles to the goal, weigh local context, and bring decisions to the user rather than acting alone or silently deferring. The bootstrap guidance supports this in its theory, but the operational checklists that the agent actually follows do not require it, so a generated `AGENTS.md` may omit it.
+
+Second, the exploratory phase has no alignment-confirmation step. The agent assesses intake adequacy, resolves gaps through inference and scope narrowing, and passes the build readiness gate, then builds. It never confirms its synthesized understanding with the user. When the readiness decision rested on the agent's own guesses, construction can start misaligned with the user's intent.
+
+## Goal
+
+A generated `AGENTS.md` reliably carries the skill's core principles and a decision stance that enables aligned local decisions. The bootstrap agent confirms its synthesized understanding with the user before it starts building the skill.
+
+## Part 1: Goals and values for local decisions
+
+The descendant's `AGENTS.md` is the model. Its core-principles section states each durable principle with its rationale, and its decision stance tells a future agent how to act when the exact instruction does not fit: diagnose, weigh local context, and confirm with the user.
+
+The theory already exists. `cross-intelligence-communication.md` states "Give future agents enough reasoning to make local decisions" and prescribes a "Writing Repository Agent Instructions" pattern with values and local judgment rules. The gap is in the operational checklists.
+
+Update the `Generated AGENTS.md Rules` checklist in `cross-intelligence-communication.md` to require a core-principles-and-decision-stance section.
+
+Update the `Maintenance AGENTS.md Requirements` in `cleanup-and-boundaries.md` to require the same, aligned with the cross-intelligence wording.
+
+## Part 2: Alignment confirmation before construction
+
+Add an alignment-confirmation step to `intake-adequacy-and-resolution.md`. After the build readiness gate passes and before writing `src/SKILL.md`, the agent presents a short synthesis the user can confirm or correct: the skill candidate and goal, the activation and non-activation boundary, the core workflow in outline, the key assumptions the decision depends on, and anything narrowed or deferred.
+
+Frame it to avoid the existing `Questionnaire Transfer` pitfall. The agent presents synthesized understanding, not a list of design questions. The agent does the design; the user confirms the direction. Scale the step to how much the readiness decision rested on inference rather than direct evidence.
+
+Add a gate in `build-skill-from-intake.md` between Phase 2 (Skill Design) and Phase 3 (Build The Skill Product), so the confirmation happens once the design synthesis exists and before construction.
+
+Add a must-follow rule to the template `AGENTS.md`: do not start `src/SKILL.md` until the build readiness gate passes and the agent's understanding is confirmed with the user.
+
+Add the confirmation to the Phase 0 completion criteria in `intake-adequacy-and-resolution.md`.
+
+## Decisions
+
+The changes target the operational checklists and the phase sequence rather than the theory, because the theory already endorses both goals: reasoning for local decisions and user alignment. The risk was that the checklists let an agent skip them.
+
+The alignment-confirmation step is explicitly distinguished from the resolution ladder's `Ask` rung. `Ask` resolves a specific blocking gap. Alignment confirmation validates the agent's overall interpretation so construction starts from shared understanding.
+
+## Part 3: Reader-standpoint language alignment
+
+An audit of the bootstrap control plane found the instruction files opened in author and provenance voice ("This file is a distilled operational version of TechSpokes research"), referenced private research the executing agent cannot see, and omitted recently added directories from the repository-shape and cleanup guidance.
+
+Reframe the opening of each bootstrap instruction file to address the executing agent and its task. Keep authorship attribution in `docs/PROVENANCE.md` and the README, not in each operational file. Remove references to private research the reader cannot access.
+
+Document `.plans/` and `.skill-template-feedback/` in the repository-shape trees, and add the feedback-folder install and the `.plans/` deletion to the Phase 7 cleanup steps, so the workflow and the shape guidance agree with `cleanup-and-boundaries.md`.
+
+Do not vendor or expose the private theory or approaches the template distills. The instruction files carry only the operational, public-appropriate form.
+
+## Verification
+
+Confirm `cross-intelligence-communication.md` and `cleanup-and-boundaries.md` require a core-principles-and-decision-stance section in the generated `AGENTS.md`.
+
+Confirm the bootstrap instruction files open by addressing the executing agent, and that no file references private research material.
+
+Confirm `intake-adequacy-and-resolution.md` has an alignment-confirmation step that is distinguished from the `Ask` rung and scaled to the reliance on inference.
+
+Confirm `build-skill-from-intake.md` gates Phase 3 on the confirmation, and the template `AGENTS.md` carries the must-follow rule.
+
+Run `npm run validate` to confirm template mode is intact.

.plans/0011-distill-authoring-guidance.md

@@ -0,0 +1,35 @@
+# 0011: Distill authoring and reasoning guidance into the bootstrap docs
+
+Issue: none. Requested directly after reviewing the TechSpokes source corpus the template draws on.
+
+Status: in-progress (implemented on `template-community-and-bootstrap`)
+
+Layer: bootstrap guidance (`.template/bootstrap/*.md`).
+
+## Problem
+
+The template distills a body of TechSpokes guidance, credited in `docs/PROVENANCE.md`: the cross-intelligence communication theory, the AGENTS.md and README specifications, and a problem-solving framework. The bootstrap docs captured the core but left out several concrete, publishable rules that make the agent's output more consistent.
+
+## Goal
+
+Strengthen the bootstrap guidance with distilled, paraphrased operational rules from the source material, written in the template's own voice. Do not vendor or quote the private theory, its formulas, its translation matrix, its cited figures, or the problem-solving framework's taxonomy and schemas.
+
+## What was added
+
+`theory-context.md` gains a "How Meaning Survives Transport" section: write for one-way delivery, protect the weakest stage by stating the goal, track goal survival separately from rule survival, treat distortion as worse than loss, design for the specific boundary crossed, and repeat critical constraints on purpose.
+
+`cross-intelligence-communication.md` gains the AGENTS.md authoring shape: the section order, read-depth guidance in the Summary, an under-100-line size target, and the rule to write `AGENTS.md` only when a standalone Summary is useful.
+
+`skill-quality-standard.md` gains README required elements, anti-patterns, and sizing, plus a `Script Rules` section for commenting any scripts a generated skill ships.
+
+`intake-adequacy-and-resolution.md` gains an "Asking High-Value Questions" section: ask only for genuine gaps, phrase questions as confirm-or-refute tests, ask the question that separates competing interpretations, separate fixed constraints from preferences, do not promote nearby mentions to requirements, and recompute gaps after each answer.
+
+## Decisions
+
+Each addition is paraphrased and kept digestible: headed sections, flat atomic lists, short rationale. The private theory's formal apparatus and the framework's implementation details were deliberately excluded; only the generic, publishable principles were reflected.
+
+The script-commenting rule is self-contained rather than pointing to a specific installed skill, so it stays portable in a generated repository.
+
+## Verification
+
+Confirm the four bootstrap docs carry the additions, that no proprietary formula, matrix, figure, or taxonomy appears, and that `npm run validate` passes.

.template/bootstrap/build-skill-from-intake.md

@@ -1,6 +1,6 @@
 # Build Skill From Intake
 
-This file is part of the TechSpokes Skill Base Template bootstrap system. It distills TechSpokes guidance on agent skill creation, instruction design, and repository maintenance into an actionable workflow.
+This file is the end-to-end workflow an agent follows to build a skill from intake.
 
 ## Goal
 
@@ -76,7 +76,7 @@ Use `.template/bootstrap/intake-adequacy-and-resolution.md` for the full procedu
 
 If intake is adequate, record the assessment and continue to Phase 1.
 
-If intake is missing build-critical evidence, resolve the gap through extraction, inference, safe discovery, scoped experiments, scope narrowing, minimal human clarification, or a documented stop. Do not start `src/SKILL.md` until the build readiness gate passes.
+If intake is missing build-critical evidence, resolve the gap through extraction, inference, safe discovery, scoped experiments, scope narrowing, minimal human clarification, or a documented stop. Do not start `src/SKILL.md` until the build readiness gate passes and the agent's understanding is confirmed with the user.
 
 Required temporary artifacts:
 
@@ -115,6 +115,10 @@ The design note is temporary. Move durable architecture information into `docs/A
 
 Rationale: The design note gives the bootstrap agent a place to reason before committing to permanent files. Durable decisions move into docs because future maintainers need the why, not the temporary scratchpad.
 
+Before Phase 3, confirm this design synthesis with the user. Present the skill candidate, goal, activation and non-activation boundary, workflow outline, and key assumptions, and ask the user to confirm or correct them. See the alignment confirmation step in `.template/bootstrap/intake-adequacy-and-resolution.md`. Do not begin construction until the direction is confirmed.
+
+Rationale: The agent has now synthesized a design from intake and its own inferences. Confirming the direction before construction keeps the skill aligned with the user's intent and makes a correction cheap relative to rebuilding.
+
 ## Phase 3: Build The Skill Product
 
 Build the product surface in `src/`.
@@ -230,13 +234,18 @@ Convert the repository to maintenance mode after the generated skill is accepted
 
 Required cleanup:
 
+- Install `.skill-template-feedback/` in the repository root from `.template/generated/`, and confirm its git-ignore pattern is present.
+- Harden the repository as described in `.template/bootstrap/cleanup-and-boundaries.md`.
 - Delete `.template/`.
+- Delete `.plans/`.
 - Rewrite `README.md` for the generated skill.
 - Rewrite `AGENTS.md` for maintaining the generated skill.
 - Keep `.intake/README.md` if future raw update intake is useful.
 - Remove raw intake files when they should not remain in source control.
 - Ensure release packaging excludes `.template/` and `.intake/`.
 
+Use `.template/bootstrap/cleanup-and-boundaries.md` for the full handoff, including repository hardening, the community file rewrites, and the feedback-folder details.
+
 Rationale: Cleanup converts the repository's identity. Before cleanup, the repository is a skill factory. After cleanup, it is the skill.
 
 ## Completion Criteria

.template/bootstrap/cleanup-and-boundaries.md

@@ -1,7 +1,5 @@
 # Cleanup And Boundaries
 
-This file is a distilled operational version of TechSpokes guidance on repository handoff, authority boundaries, and maintenance-mode transition.
-
 ## Goal
 
 Convert a generated repository from bootstrap mode to maintenance mode without leaking bootstrap instructions into the final skill.
@@ -62,6 +60,8 @@ The final `AGENTS.md` must support future maintenance.
 It should include:
 
 - The generated skill's maintenance goal.
+- The skill's core principles, each with the rationale it protects.
+- A decision stance for how a future agent should act when the exact instruction does not fit.
 - Required validation commands.
 - A short statement of how changes land, pointing to `docs/RELEASING.md`.
 - Skill reference organization rules.
@@ -70,6 +70,8 @@ It should include:
 
 Make `docs/RELEASING.md` the single source for how changes land and how a release is cut. Point `AGENTS.md` and `CONTRIBUTING.md` to it rather than repeating the steps, so the documents never drift apart.
 
+The core principles and the decision stance are how the skill's goals and values reach future agents who make local decisions. State each principle as a durable commitment with its reason. State the decision stance concretely: diagnose the situation against the skill's goal, weigh the local context, and bring the decision to the user rather than acting alone or silently deferring.
+
 The final `AGENTS.md` should explain why important boundaries exist. A future agent can adapt a rule responsibly only when it understands the value the rule protects.
 
 ## GitHub Community File Handoff