@boopkit/cap-product-design 0.6.10 → 0.6.12
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/capability.json
CHANGED
|
@@ -10,6 +10,7 @@
|
|
|
10
10
|
"boop-product-design-feature-documentation",
|
|
11
11
|
"boop-product-design-feature-requirements",
|
|
12
12
|
"boop-product-design-reference-integration",
|
|
13
|
+
"boop-product-design-knowledge-backfill",
|
|
13
14
|
"boop-product-design-thought-partnership",
|
|
14
15
|
"boop-writing-technical-prose",
|
|
15
16
|
"boop-writing-documents",
|
package/package.json
CHANGED
|
@@ -39,7 +39,7 @@ For UI features, the same principle applies one level deeper: the hardest part i
|
|
|
39
39
|
- **Alternatives section earns trust** — showing what you rejected (and why) is what separates a design from a description
|
|
40
40
|
- **Details should be selective** — document the tricky parts and link to the rest; don't rewrite the code in prose
|
|
41
41
|
- **Prefer grounded terminology** — name things with generally-accepted software-engineering and product terms, and reuse the codebase's own names for things that already exist; avoid coined metaphors and vague shorthand ("the spine," "the gate," "the fix"). A design doc full of private labels costs every reader a translation pass. See `boop-writing-technical-prose` (anti-pattern 13).
|
|
42
|
-
- **Design docs live in `specs/`** — see
|
|
42
|
+
- **Design docs live in `specs/`** — see `boop-project-mgmt-engineering-planning` for how designs become work plans
|
|
43
43
|
|
|
44
44
|
## For refactor specs: audit current state first
|
|
45
45
|
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: boop-product-design-knowledge-backfill
|
|
3
|
+
description: "When you need to integrate new knowledge from a set of specs or completed work that was not documented in reference at the time it shipped. This often happens when a feature is developed under a tight deadline and the team prioritizes shipping over documentation, or when work was done before the reference system was fully established."
|
|
4
|
+
metadata:
|
|
5
|
+
category: docs
|
|
6
|
+
---
|
|
7
|
+
> **Read `PROJECT.md`, beside this file, first.**
|
|
8
|
+
> It records how this project applies the guidance below, and where it deliberately differs.
|
|
9
|
+
> Where the two conflict, `PROJECT.md` wins.
|
|
10
|
+
> Record project-specific rules there, never in this file.
|
|
11
|
+
|
|
12
|
+
# Knowledge Backfill
|
|
13
|
+
|
|
14
|
+
**a. Integrate into reference:**
|
|
15
|
+
- Follow the `boop-product-design-reference-integration` skill to blend the new feature's knowledge into existing `reference/` pages.
|
|
16
|
+
- This is NOT "create a new page for the feature" — it's merging knowledge into the existing concept pages (and creating new concept pages only when a genuinely new concept has no home).
|
|
17
|
+
- Update cross-links between affected reference pages.
|
|
18
|
+
- Remove or update any reference content that is now outdated.
|
|
19
|
+
|
|
20
|
+
**b. Archive the spec:**
|
|
21
|
+
- Move the completed spec from `specs/` to `specs/history/` (create the directory if it doesn't exist).
|
|
22
|
+
- If any aspects of the spec were NOT implemented (deferred, descoped, or punted), extract those into a new revised spec in `specs/` that captures just the remaining work. Reference the archived spec for full context.
|
|
23
|
+
- The archived spec should be the full original — do not edit or trim it.
|
|
24
|
+
|
|
25
|
+
## Related
|
|
26
|
+
|
|
27
|
+
- [`boop-product-design-reference-integration`](../boop-product-design-reference-integration/SKILL.md) — for step a of every spec you process; this workflow decides what to backfill and in what order, and that skill decides where each piece lands on the page.
|
|
28
|
+
- [`boop-writing-technical-prose`](../boop-writing-technical-prose/SKILL.md) — when extracting the unimplemented remainder into a revised spec; that spec is read cold by someone with none of the backfill's context.
|
|
@@ -87,4 +87,4 @@ A `SKILL.md` the project has edited is not blended: its edits move into the `PRO
|
|
|
87
87
|
|
|
88
88
|
- [`boop-writing-semantic-line-breaks`](../boop-writing-semantic-line-breaks/SKILL.md) — `reference/` pages are edited far more often than they are written; semantic line breaks are what keep those edits reviewable.
|
|
89
89
|
- [`boop-writing-technical-prose`](../boop-writing-technical-prose/SKILL.md) — when blending new content into an existing page; the merged paragraph has to read as though it was always there, and matching a page's voice starts with writing full sentences.
|
|
90
|
-
- `boop-knowledge-backfill` — when the gap is not one feature's knowledge but a backlog of shipped work that was never written down; that workflow decides what to process and in what order, then sends each spec back here.
|
|
90
|
+
- [`boop-product-design-knowledge-backfill`](../boop-product-design-knowledge-backfill/SKILL.md) — when the gap is not one feature's knowledge but a backlog of shipped work that was never written down; that workflow decides what to process and in what order, then sends each spec back here.
|