Defame1297/holocron
0
0
Fork 0
Code Issues 14 Pull Requests Actions Packages Projects Releases 3 Wiki Activity

docs: Chunk 3 issues 0015-0028 and doc updates

Browse Source 
14 issues created covering AGENTS.md refactor prerequisite, skill
implementation workflow grill, bootstrap skills (write-eval, write-skill),
remaining factory skills, and one issue per skill category group through
to chunk closure. All HITL; acceptance criteria for 0017-0028 to be
refined after 0016 grill session.

Doc updates: CONTEXT.md PRD/issue scope clarified (HOW distribution
across architecture-review and issue design notes); ROADMAP.md housekeeping
updated with bootstrap order and issue range; spec/overview.md recent
changes entry added; PRD updated (skills-index: delete → update).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Defame1297
2026-05-17 15:18:36 +00:00
parent 537c681bb9
commit 9457efff36
18 changed files with 681 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
CONTEXT.md
View File

@@ -116,10 +116,10 @@ Skills and workflows reference "linked issue" generically rather than a specific
The canonical pre-implementation sequence within any workstream: `grill-lean` (optional lightweight interrogation, no docs) → `grill-me` (primary: deep interrogation + domain alignment + ADR writing) → `write-prd` (why + what only, never how) → `architecture-review` (optional: technical approach evaluation, ≥2 options) → `break-into-issues` (independently shippable slices; proposes Gitea milestone groupings for PRDs producing >5 issues).
### PRD scope
A PRD contains: problem statement, goals, explicit non-goals, functional requirements at feature level, success criteria. Never contains: technical approach, implementation steps, or EARS-level detail (that is issue scope). Prerequisite: a completed grill session. Validated by inline self-checks in the `write-prd` skill.
A PRD contains: problem statement, goals, explicit non-goals, functional requirements at feature level, success criteria. Never contains: technical approach, implementation steps, or EARS-level detail. HOW is handled downstream: workstream-level technical approach belongs in `architecture-review` (≥2 options, tradeoffs, optional step after `write-prd`); issue-level HOW belongs in issue design notes. Prerequisite: a completed grill session. Validated by inline self-checks in the `write-prd` skill.
### Issue scope
An issue contains: link to parent PRD (inherited why) + one-line context for this slice, EARS-format acceptance criteria, brownfield delta markers (ADDED/MODIFIED/REMOVED), design notes (non-trivial issues only), independently completable task checklist. Prerequisite: parent PRD linked, or explicit standalone justification. No issue may block another open issue. Validated by inline self-checks in `write-issue-spec` and `break-into-issues`.
An issue contains: link to parent PRD (inherited why) + one-line context for this slice, EARS-format acceptance criteria, brownfield delta markers (ADDED/MODIFIED/REMOVED), design notes for non-trivial issues (the issue-level HOW — implementation specifics scoped to this slice only), independently completable task checklist. Prerequisite: parent PRD linked, or explicit standalone justification. No issue may block another open issue. Validated by inline self-checks in `write-issue-spec` and `break-into-issues`.
### Bidirectional reference principle
Files that reference other files should declare those references explicitly. The referencing file carries the forward reference (e.g. content index in `CLAUDE.md`, `references:` in frontmatter). The referenced file carries a `when:` field describing when it is loaded. Both sides should agree — divergence signals staleness. The reverse map ("what files reference this file?") is derived by a reference scanner script (Chunk 6 tooling), not maintained manually. This principle applies to instruction files, skills, and workflow documents.