@mriekki/project-forge 0.0.0-stage → 2.0.0

package/assets/generated/core/core/skills/wait-what/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: wait-what
+description: "The last explanation did not land. Re-explain it with enough context to understand where we are and what happens next."
+argument-hint: "[optional note about what was unclear]"
+user-invocable: true
+disable-model-invocation: true
+---
+
+# Wait, What?
+
+Purpose: repair communication when the immediately preceding explanation did not land.
+
+This skill re-explains. It does not perform new engineering work.
+
+## 1. Use existing context first
+
+Re-pitch the immediately preceding explanation, or the specific unclear point named by the human.
+
+Prefer already-available conversation/repository context. Do not run commands, inspect new Git/GitHub state, modify files, or take the next workflow action merely to explain the prior response.
+
+If a safe explanation depends on information that is genuinely missing, say what is missing instead of inventing it.
+
+## 2. Use plain technical English
+
+Prefer:
+- short, direct sentences;
+- concrete nouns instead of vague pronouns;
+- one idea per sentence when possible;
+- familiar repository/work-item terminology;
+- explicit cause-and-effect language;
+- examples only when they make the explanation clearer.
+
+Use a Simplified-Technical-English style, but do not claim formal ASD-STE100 compliance.
+
+When repository glossary material exists, prefer its terminology. A glossary is helpful, not required.
+
+## 3. Re-establish orientation
+
+For a substantive explanation, cover only what helps:
+
+```text
+CURRENT CONTEXT
+Where we are and what led here.
+
+WHAT I MEANT
+The important point in simpler language.
+
+WHY IT MATTERS
+Why the point affects the current work or decision.
+
+WHAT HAPPENS NEXT
+The immediate next step, if there is one.
+```
+
+Do not force all headings for a tiny clarification. Keep the response proportional to the confusion.
+
+## 4. Respect human gates
+
+If the unclear explanation immediately preceded a human approval or consequential-action gate, complete the re-explanation before asking for that approval again.
+
+Do not treat `/wait-what` as approval to continue, write files, commit, push, merge, deploy, or call external systems.
+
+## 5. Route deeper needs without changing modes silently
+
+If the human actually needs:
+- current workflow-state orientation, suggest `/next-step`;
+- deeper concept teaching, suggest `/coach`;
+- a structured explanation of implementation changes, suggest `/code-walkthrough`;
+- an understanding check, suggest `/learning-review`.
+
+Do not silently switch into those modes unless the human asks.
+
+## 6. Boundaries
+
+`/wait-what` is:
+- read-only,
+- user-invoked,
+- non-blocking,
+- communication-focused,
+- usable during requirements, planning, implementation, review, delivery, setup, learning, or operations discussions.
+
+It does not create a new engineering workflow state.
+
+## Provenance
+
+Inspired by Matt Pocock's `wait-what` productivity skill in `mattpocock/skills` (MIT licensed). This Project Forge Core version is independently rewritten for repository-agnostic Human-in-the-Loop engineering workflows.

package/assets/generated/core/core/templates/ADR_TEMPLATE.md

@@ -0,0 +1,41 @@
+# ADR-NNN — <Decision title>
+
+Status: **PROPOSED**
+
+Date: `<YYYY-MM-DD>`
+
+## Context
+
+What engineering/product constraint or tradeoff requires a durable decision?
+
+## Decision
+
+What was decided?
+
+Do not mark an ADR accepted until the human/repository process has actually accepted the decision.
+
+## Alternatives considered
+
+- `<alternative>` — why it was considered and why it was not selected.
+- `<alternative>` — why it was considered and why it was not selected.
+
+## Tradeoffs / consequences
+
+### Benefits
+
+- `<benefit>`
+
+### Costs / risks
+
+- `<cost or risk>`
+
+## Evidence / links
+
+- Work item: `<ID or link>`
+- Relevant code/config: `<path>`
+- System Lab scenario/component: `<reference when useful>`
+- Other docs: `<link>`
+
+## Follow-up / review trigger
+
+What future condition should cause this decision to be revisited?

package/assets/generated/core/core/templates/FEATURE_BRIEF_TEMPLATE.md

@@ -0,0 +1,27 @@
+# Feature Brief — <Name>
+
+> Authority: <AUTHORITATIVE | SUPPLEMENTAL / EXPERIMENTAL>
+>
+> Jira relationship: <Epic / Story set / other>
+>
+> A Jira Epic is not automatically equivalent to this Feature Brief.
+
+## Problem / User Outcome
+
+## Scope
+
+## Non-Scope
+
+## Workflows
+
+## Cross-Story / Domain Rules
+
+## Dependencies
+
+## Related Jira Epics / Stories
+
+## Acceptance Summary
+
+## Open Decisions
+
+## Approval / Status

package/assets/generated/core/core/templates/PRODUCT_BRIEF_TEMPLATE.md

@@ -0,0 +1,27 @@
+# Product Brief — <Name>
+
+> Authority: <AUTHORITATIVE | SUPPLEMENTAL / EXPERIMENTAL>
+>
+> External system relationship: <for example Jira Epics/Stories remain primary>
+
+## Problem / Opportunity
+
+## Users / Stakeholders
+
+## Desired Outcomes
+
+## Scope
+
+## Non-Scope
+
+## Major Workflows / Capabilities
+
+## Domain / Policy Constraints
+
+## Success Measures
+
+## Related Jira Epics / Work Items
+
+## Open Decisions
+
+## Approval / Status

package/assets/generated/core/core/templates/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,37 @@
+<!--
+Internal PR-body scaffolding for the Project Forge delivery workflow.
+Populate from actual work-item, diff, test, review, and CI evidence.
+Do not mark checks complete unless the evidence was observed.
+-->
+
+## Work item
+
+<!-- ID and concise title -->
+
+## What changed
+
+-
+-
+-
+
+## Acceptance evidence
+
+- [ ] Relevant local formatting/build/test/checks pass
+- [ ] Relevant runtime/browser/container checks pass when applicable
+- [ ] GitHub Actions passes
+
+Mark items N/A in notes when they do not apply.
+
+## Review
+
+- [ ] Project Forge Reviewer completed when required by the work classification
+- [ ] Blocking findings resolved
+- [ ] Human final PR diff review completed
+
+## Known limitations / follow-up
+
+-
+
+## Notes
+
+<!-- Keep concise. Link to authoritative work-item docs instead of duplicating requirements. -->

package/assets/generated/core/core/templates/REQUIREMENTS_TEMPLATE.md

@@ -0,0 +1,17 @@
+# Detailed Requirements — <Work Item>
+
+> Use only when local detailed requirements are permitted and useful.
+>
+> Do not duplicate Jira/Issue authority without an explicit reason.
+
+## User / Engineering Outcomes
+
+## Domain / Engineering Requirements
+
+## Acceptance / Validation Scenarios
+
+## Open Decisions
+
+## Traceability
+
+## Authority / Approval

package/assets/generated/core/profiles/greenfield/project-forge-workspace.json

@@ -0,0 +1,12 @@
+{
+  "schemaVersion": 1,
+  "profile": "greenfield",
+  "workItemSource": "local-docs",
+  "productBriefs": {"mode": "authoritative"},
+  "featureBriefs": {"mode": "authoritative"},
+  "engineeringEnablers": {"mode": "authoritative"},
+  "localDetailedRequirements": {"mode": "authoritative-combined"},
+  "jira": {"accessMode": "none", "epics": "not-used"},
+  "delivery": {"pr": true, "explicitFinalPrAcceptance": true, "explicitMerge": true, "postMergeCi": "observe-if-configured"},
+  "productionReadiness": {"enabled": "when-production-in-scope"}
+}