This repository contains shared governance, community health files, contribution conventions, issue and pull-request templates, engineering prompts, standards, automation, shared skill defaults, and reusable guidance for repositories in the hackelia-micrantha organization.
Repositories may refine these defaults when their product, legal, security, or operating model requires it, but should document the difference explicitly. Repository-local implementation and evidence remain authoritative within the boundaries assigned by the organization governance model.
Use the repository that owns the question:
| Question | Source of truth |
|---|---|
| How should Micrantha repositories be governed and engineered? | This repository (hackelia-micrantha/.github) |
| What shared skill defaults are available? | skills/ in this repository |
| What operational skills does a specific project use? | The owning project repository |
| What Micrantha projects exist, what are their roles/lifecycles, and how do they relate? | hackelia-micrantha/hackelia-micrantha |
| What does a specific product/library/tool implement? | The owning project repository |
| What is presented publicly? | micrantha.com and profile/README.md, as evidence-backed projections |
The meta/registry repository coordinates ecosystem identity, relationships, and skill discovery/composition; it does not own organization GitHub policy or project-local operational skills. This repository defines shared defaults and responsibility boundaries; it does not become a second implementation source of truth for projects.
- Organization governance
- Contribution and issue-prioritization standard
- Repository lifecycle and maturity
- Repository responsibility catalogue
- Repository topology and trust-domain patterns
- Security policy
- Support guidance
- Code of conduct
The governance model defines accountable roles, decision authority, repository and contract ownership, security-risk acceptance, release authority, lifecycle control, and boundaries for AI-assisted or agentic engineering.
The repository catalogue distinguishes architectural authority from runtime dependency. A laboratory produces evidence without silently redefining a product contract; a distribution composes components without assuming their internal authority; a public site projects evidence rather than creating product truth.
Repository topology is also explicit: provider, visibility, and labels such as canonical, private, public, agent, or mirror describe topology or policy context. They do not independently grant read, write, publication, merge, promotion, or synchronization authority.
The standards define minimum outcomes according to repository classification, maturity, risk, supported surface, and deployment model. Repository-local standards may be stricter or may document a justified alternative control, but cannot silently weaken security, compatibility, release, support, or public-maturity claims.
Micrantha operator-facing command-line tools should remain ordinary composable tools rather than requiring an agent-specific invocation path. The shared CLI contract covers stable machine-readable stdin/stdout, human-vs-machine output separation, exit semantics, broken-pipe behavior, side-effect boundaries, and man-page expectations.
The same semantic contracts may be consumed by supervisor/orchestration layers. Orchestration should not create a second incompatible result model merely because the caller is an agent.
- Automation foundation
- Machine-readable repository registry
- Repository registry schema
- Workflow starter templates
- Reusable mise CI workflow
- Reusable Nix CI workflow
- Repository-health workflow
The automation layer is read-only by default. Starter templates help repositories adopt common workflow structure; repositories still own their tasks, test coverage, runner trust decisions, required checks, and release policy. Shared reusable workflows do not inherit secrets or perform deployment, release, approval, label, or repository-setting mutations.
The repository registry is an advisory machine-readable projection of the canonical responsibility catalogue. A weekly health report checks registered location, visibility, default branch, archival state, and minimal required files without opening issues or modifying repositories. Private-repository coverage requires an explicitly configured read-only token.
- Engineering work-item guide and decision templates
- Shared engineering skills — reusable defaults/reference contracts; operational skills remain project-local by default
- ChatGPT Supervisor operating profile — versioned bootstrap profile for recursive ChatGPT/Work + GitHub/Desktop Commander engineering sessions
- Compound engineering — Plan → Work → Review → Compound → Repeat
- AI-assisted SDLC phase discipline — explicit phase-local context, durable handoffs, verification, review, and authority boundaries
- AI model selection and escalation — risk-adaptive model choice; frontier inference is an escalation option rather than a universal requirement
- Compound artifact routing — route reusable lessons to the weakest durable control that reliably prevents recurrence
- Governed learning promotion — candidate learning, validation, exact promotion, supersession, and authority boundaries
- Compound learning runtime boundaries — Supervisor, Run Ledger, Memory, Invokrum, Sandcastle, Anthesis, and scheduler ownership
- Engineering prompt library
- Project review prompts
- Pull-request merge-gate review
- CI failure triage and repair
- Classify and route engineering work
- Next executable slice
- Issue grooming
- QART decision analysis
- RFC development
- QART-to-ADR conversion
- Engineering artifact review
- Implementation completeness review
- Compound review
- Cross-repository boundary review
- Release readiness review
- Public documentation consistency review
- Agentic workflow security review
Repositories without local overrides inherit specialized forms for bugs, features, security intake, engineering delivery slices, design proposals, and epics or plans, plus the organization pull-request template and issue chooser guidance.
Use the most specific issue form that fits:
- bug for an observable defect;
- feature for a requested capability;
- security for non-sensitive public intake, with detailed reports handled privately;
- engineering delivery slice for bounded cross-cutting implementation, integration, migration, infrastructure, or refactoring work;
- design proposal for material unresolved design questions without prematurely assuming RFC status;
- epic or plan for coordination across bounded workstreams and outcomes.
A repository that defines local files under .github/ISSUE_TEMPLATE/ may stop inheriting the organization issue-template directory. Local overrides should therefore copy or deliberately replace the shared chooser and required forms rather than accidentally removing them.
The pull-request template requires the outcome, authority and related decisions, scope, validation evidence, security and governance impact, compatibility and rollback behavior, documentation and release effects, and remaining work.
Use the comprehensive project review when a project lacks a trustworthy baseline, has unclear architecture or maturity, or needs backlog reconciliation. Use the status refresh after meaningful merges, releases, incidents, milestone changes, or planning cycles.
For new work:
classify the material
-> gather evidence or run a bounded spike when facts are missing
-> use QART when credible alternatives remain open
-> use an RFC only when broad or cross-boundary review is warranted
-> obtain accountable disposition
-> record accepted durable decisions in ADRs
-> coordinate larger outcomes through epics or plans
-> deliver bounded implementation slices
-> review against the current authoritative work item
-> Compound reusable lessons when meaningful
-> validate, release, operate, and update public evidence
The Compound stage asks: Would the system catch or prevent this automatically next time? Prefer tests, schemas, invariants, CI checks, safer tools, or other deterministic controls when the behavior is mechanically decidable. No reusable learning is a valid result.
Candidate learning remains non-authoritative. In particular:
historical Memory/context
!= exact promoted guidance
!= effect authority
Reusable prompt/context guidance should be composed as an exact candidate Invokrum pack/overlay and lock, evaluated, and separately promoted through the owning authority. Memory may index historical or promoted references but cannot establish currentness; trusted consumption re-resolves current/not-revoked/not-superseded state from the owner. Sandcastle may provide exact checkpoint/verifier isolation, while Anthesis governs promotion where persistent trusted control or policy is affected. Scheduler timing never creates semantic or promotion authority.
Prioritization for tracked engineering work follows CONTRIBUTING.md:
P0— active interrupt;P1— small executable next-up queue;P2— planned work;P3— later or exploratory work.
Priority remains distinct from severity, status, size, confidence, age, and architectural importance. Blocking is recorded as status while preserving the underlying priority. Intake reporters are not expected to determine repository-global priority; maintainers assign it during grooming and triage.
Maturity is evidence-based and separate from repository classification or architectural role:
- Proposed
- Experimental
- Incubating
- Active
- Stable
- Maintenance
- Superseded
- Archived
The public aliases Prototype and Maintained map to Experimental and Maintenance. Lifecycle changes should update the repository, the catalogue, the appropriate registry projection, and relevant public documentation together.