Repository: jasonkronemeyer/jasonkronemeyer.github.io
Prototype branch: prototype/contribution-framework
Delivery: Draft pull request only, with no automatic merge
Status: Prototype specification
Prototype a reusable contribution and discussion framework for Jason Kronemeyer’s Jekyll-based public knowledge repository. The framework will make eligible articles, research notes, development notes, maps, prototypes, frameworks, and other documents open to structured review, correction, evidence submission, discussion, and revision.
The initial implementation must add a context-aware contribution panel to the bottom of eligible rendered pages. It must also establish the architecture for expandable, nested, newsgroup-style discussions that can remain associated with the document and, when technically practical, be explored without leaving the page.
The site should evolve from a publication pipeline into a versioned participation and provenance system:
Idea -> Note -> Evidence -> Discussion -> Issue -> Pull Request -> Revision -> Publication
Use the strongest reasoning and coding model available in the GitHub Copilot model picker for the initial architecture and implementation. Prefer a model that is optimized for agentic software development, repository-wide reasoning, terminal use, multi-file editing, and test-driven verification.
Because GitHub Copilot model availability varies by plan, client, policy, and release date, do not hard-code an unverified model identifier. In Visual Studio Code, use the custom-agent model: autocomplete to choose an available model. If the project-specific custom agent must remain portable, omit model: so it inherits the selected or default model.
The selected model should be demonstrably strong at:
Use a faster, lower-cost model only for bounded follow-up work such as wording changes, repetitive metadata updates, or minor CSS adjustments.
The coding agent must understand:
_includes, _layouts, _data, _config.yml, and custom collections;url, baseurl, permalinks, canonical URLs, and GitHub Pages constraints;The agent must distinguish among published articles, research notes, development notes, maps, datasets, prototypes, frameworks, early-stage ideas, archived documents, and documents closed to public contribution.
The agent must implement semantic HTML, keyboard operation, visible focus states, sufficient contrast, descriptive labels, responsive rendering, screen-reader support, reduced-motion compatibility, and accessible loading and error states.
The agent must not expose secrets, add tokens to client-side code, change repository visibility, publish private content, enable protected content for contribution, add unreviewed third-party scripts, or represent technical controls as legal patent protection.
Use branch:
prototype/contribution-framework
If it already exists, use:
prototype/contribution-framework-v2
The agent must:
Suggested commits:
feat: add reusable contribution panel
feat: add contribution metadata and defaults
feat: add threaded discussion interface shell
feat: add issue forms and pull request template
docs: add contribution and intellectual property guidance
test: add contribution link and rendering validation
style: add responsive contribution and discussion styles
Inspect at minimum:
_config.yml
Gemfile
Gemfile.lock
.github/
_includes/
_layouts/
_data/
_sass/
assets/
_posts/
all custom collection directories
Identify:
Include the findings in the draft pull request.
Create:
_includes/contribution-panel.html
Render it from site defaults, page front matter, and discoverable repository metadata. Avoid hard-coding the current repository when a reliable configurable value is available.
Insert the component into the lowest appropriate shared layout so it appears after substantive content and before the global footer. Do not edit hundreds of Markdown files individually.
{% unless page.contributions.enabled == false %}
{% include contribution-panel.html %}
{% endunless %}
Support configurable actions for:
Generate links for the current source document:
https://github.com/OWNER/REPOSITORY/edit/BRANCH/PATH
https://github.com/OWNER/REPOSITORY/blob/BRANCH/PATH
https://github.com/OWNER/REPOSITORY/commits/BRANCH/PATH
Issue links should prepopulate the document title, public URL, source path, contribution category, privacy warning, and relevant checklist.
URL-encode all dynamic titles, paths, labels, and query values. Test spaces, apostrophes, colons, ampersands, question marks, parentheses, and Unicode.
Optionally display document type, maturity, version, last-reviewed date, contribution status, peer-review status, and applicable license or terms.
Use contribution prompts appropriate to the document type:
Support:
contributions:
enabled: true
edit: true
issues: true
evidence: true
questions: true
discussions: true
source: true
history: true
peer_review: true
status: open
Allow individual actions or the entire component to be disabled.
Support:
intellectual_property:
review_required: false
public_disclosure_approved: true
If review_required is true or public_disclosure_approved is false, suppress public edit, issue, and discussion prompts by default and display a neutral closed-contribution notice. This is a workflow safeguard, not legal protection or patent advice.
Add site-level defaults through _config.yml or an appropriate data file:
github_repository:
owner: jasonkronemeyer
name: jasonkronemeyer.github.io
default_branch: main
discussions_enabled: false
contribution_defaults:
enabled: true
edit: true
issues: true
evidence: true
questions: true
discussions: true
source: true
history: true
peer_review: false
status: open
First determine whether equivalent data already exists.
Support future project repositories and page-level source overrides:
source_repository:
owner: jasonkronemeyer
name: another-repository
branch: main
path: docs/example.md
Do not assume every page belongs to jasonkronemeyer.github.io.
The framework must establish a threaded discussion experience modeled on classic Internet newsgroups. Conversations must be represented as trees, not deliberately flattened into a single chronological stream.
Readers should be able to remain on the document while exploring its conversation:
Discuss this work
7 threads · 23 replies
▼ Evidence supporting this claim
Initial message
└─ Reply
└─ Nested reply
[Reply]
▶ Question about the methodology 4 replies
▶ Application to rural schools 7 replies
[Start a new discussion]
The architecture and interface shell must support:
Render long conversations in a collapsed summary by default. Expanding a thread must not navigate away from the document. Expanding one reply branch should not require expanding every branch.
Preserve logical reply depth, but cap visual indentation after approximately three or four levels. At greater depths, use styling such as connector lines, compact labels, or branch markers rather than continuing to reduce content width.
JavaScript may enhance the discussion interface, but:
Do not build a custom discussion database. Use GitHub as the preferred identity, moderation, notification, and discussion system of record. Before implementing embedded synchronization or replies, investigate and document the actual capabilities, reply-depth behavior, authentication requirements, rate limits, and constraints of the selected GitHub interface.
If the provider cannot preserve arbitrary nested replies, document that limitation and do not simulate false hierarchy.
Never embed a personal access token, private API token, repository credential, or secret in Jekyll configuration, rendered HTML, JavaScript, CSS, or public repository files. If authenticated writing is required, use a secure GitHub-supported authentication flow or send the user to the canonical GitHub interface.
Every discussion must be traceable to its originating document. Support metadata such as:
discussion:
enabled: true
provider: github
id:
category:
embedded: true
threading: nested
Avoid manual identifiers when they can be derived or managed reliably.
Phase 1 must implement the accessible discussion summary/interface shell and canonical links. Full embedded retrieval and reply behavior should be implemented only if repository discovery confirms a clean, secure, maintainable approach and the pull request clearly separates optional work from the baseline contribution panel.
Treat meaningful discussions as part of the intellectual provenance of a document.
The architecture must support eventual relationships among:
Claim -> Question -> Discussion -> Evidence -> Issue -> Pull Request -> Revision
Do not collapse these objects into one workflow.
Where practical, preserve links among related objects:
Discussion #42 -> Issue #57 -> Pull Request #63 -> Document version 0.5
Do not automatically delete or close the originating discussion when a revision is accepted. The conversation may explain why the document changed.
Design for optional metadata such as:
provenance:
discussions: []
issues: []
pull_requests: []
supersedes:
revised_from:
Do not require manual duplication when relationships can be derived reliably through GitHub references or build-time data.
Keep identifiers stable enough that future systems can express document, claim, evidence, discussion, issue, pull request, contributor, and revision relationships as connected data. Do not require a graph database in this prototype.
---
layout: research-note
title: "Example Research Note"
description: "A concise description."
document:
type: research-note
status: active-research
version: "0.4"
last_reviewed: 2026-10-22
contributions:
enabled: true
edit: true
issues: true
evidence: true
questions: true
discussions: true
source: true
history: true
peer_review: true
status: open
discussion:
enabled: true
provider: github
embedded: true
threading: nested
intellectual_property:
review_required: false
public_disclosure_approved: true
---
Demonstrate on a small sample: one article, research note, development note, prototype, map, contribution-disabled page, and IP-review page.
Create or revise:
CONTRIBUTING.md
.github/ISSUE_TEMPLATE/correction.yml
.github/ISSUE_TEMPLATE/evidence.yml
.github/ISSUE_TEMPLATE/question.yml
.github/ISSUE_TEMPLATE/technical-problem.yml
.github/ISSUE_TEMPLATE/config.yml
.github/pull_request_template.md
CONTRIBUTING.md must address accepted contributions, small edits, evidence and citations, conceptual discussions, review expectations, respectful participation, authorship, attribution, contribution licensing, material AI assistance, confidentiality, and patent-sensitive submissions.
Recommend manual Discussion categories:
Do not assume categories can be configured through repository files.
The contribution area should be distinct but restrained, inherit the site’s typography and colors, avoid unnecessary dependencies, provide usable mobile tap targets, print cleanly, and remain functional without JavaScript.
Suggested structure:
Contribute to this work
[status, version, review state]
[context-specific invitation]
[Suggest an edit] [Report a correction] [Propose evidence]
[Ask a question] [Discuss] [View source] [View history]
Discuss this work
[thread summaries with expandable nested replies]
Contribution guidelines | Code of conduct | License
Run the repository’s documented build. If none exists, attempt the appropriate equivalent of:
bundle exec jekyll build
Document exact environmental failures rather than masking them.
Verify:
Verify:
aria-expanded, labels, focus order, and keyboard behavior are correct;Confirm no breakage to navigation, pagination, collections, maps, prototypes, syntax highlighting, feeds, sitemap, SEO metadata, canonical URLs, or Pages deployment.
The prototype is complete when:
Create:
.github/agents/jekyll-collaboration-architect.agent.md
Suggested profile:
---
name: Jekyll Collaboration Architect
description: Designs, implements, tests, and documents contribution and threaded discussion features for this Jekyll knowledge repository.
# Select an available agentic coding model with repository-wide reasoning,
# or omit model to inherit the current/default model.
---
You are the collaboration architect for Jason Kronemeyer's Jekyll-based public knowledge repository.
Inspect the repository before editing. Prefer reusable includes, shared layouts, site defaults, and page-level overrides. Preserve existing content, authorship, attribution, MLA citations, design conventions, and build behavior.
Implement document-aware contribution features and an accessible shell for expandable nested discussion. Use GitHub as the system of record. Do not build a custom comments database. Do not flatten reply relationships that the provider exposes. Do not invent nesting the provider does not support.
Never expose credentials, private content, or patent-sensitive material. Pages marked for intellectual-property review must not invite public contribution. Do not change repository visibility, enable Discussions automatically, merge, or publish protected material.
Build and test the site. Validate URLs, keyboard behavior, responsive rendering, error handling, and graceful fallback. Make small commits and open a draft pull request with findings, previews, test results, limitations, manual settings, rollback instructions, and next-phase recommendations. Stop before merge.
GitHub custom agents are repository-level Markdown profiles with YAML front matter. The model property is optional; if omitted, the agent inherits the default model.
Create or update:
.github/copilot-instructions.md
Include repository purpose, Jekyll conventions, content-preservation requirements, Jason Kronemeyer’s authorship of the First Five framework, MLA 9 preservation, contribution controls, discussion architecture, IP safeguards, branch workflow, build commands, tests, and the prohibition against automatic merge.
Using the Jekyll Collaboration Architect custom agent, implement the repository-wide contribution and threaded discussion prototype described in the technical specification.
Work only in a new branch named prototype/contribution-framework. Do not merge changes into the default branch.
Begin by inspecting and documenting the current Jekyll architecture, collections, layouts, includes, theme, styles, builds, repository metadata, collaboration files, and GitHub Discussions status.
Implement a reusable, accessible contribution panel at the bottom of eligible documents. Generate document-aware actions for edits, corrections, evidence, questions, discussions, source, and history. Use site defaults and page-level overrides. Include document status, maturity, version, peer-review status, and intellectual-property controls. Content requiring IP review must not display public contribution actions.
Implement the accessible interface shell and data model for expandable top-level threads and nested replies. Preserve parent-child relationships, support independent branch expansion, cap visual indentation, retain canonical GitHub links, and fail gracefully. Use GitHub as the system of record. Do not build a custom comments database or expose credentials. Fully embedded retrieval or reply behavior is optional and must only be added if repository investigation confirms a secure, maintainable provider capability.
Create or update CONTRIBUTING.md, issue forms, the pull-request template, the custom Copilot agent, repository Copilot instructions, and supporting documentation. Recommend manual Discussion categories but do not enable settings automatically.
Demonstrate the system on a small representative sample. Do not perform a repository-wide front-matter migration.
Build and test the site. Validate generated URLs, responsive behavior, keyboard operation, nested discussion states, error fallback, and regression safety. Make small commits, push the branch, and open a draft pull request containing architecture findings, screenshots or previews, tests, limitations, manual settings, rollback instructions, and next-phase recommendations.
Stop after opening the draft pull request. Do not merge it.
The smallest successful prototype should establish a stable foundation for:
Document
-> Contribution panel
-> Discussion summary and canonical link
-> Expandable nested conversation interface
-> Evidence and issue relationships
-> Pull request and revision provenance
The discussion layer is not a generic comment section. It is part of the documented evolution of the knowledge itself.