Skip to content

fix(extract): archive-path source markers + knowledge new-file parity #10

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
BeArchiTek wants to merge 1 commit into
base: main
Choose a base branch
from
+15 −4
Open

fix(extract): archive-path source markers + knowledge new-file parity #10

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 14 additions & 3 deletions commands/extract.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -215,19 +215,30 @@ Create new files in `dev/adr/` using this format:
### Knowledge updates

For each knowledge update:
1. Read the full target file
1. Read the full target file (or create a new one if needed)
2. Find the appropriate section (match by heading)
3. Add or update content within that section
4. If the section does not exist, create it in a logical position
5. Add a source marker: `<!-- Extracted from specs/<spec-name> on YYYY-MM-DD -->`
5. Add a source marker: `<!-- Extracted from specs/archive/<spec-name> on YYYY-MM-DD -->`

If creating a new knowledge file, follow the standard structure:
```markdown
# <Topic>

## Overview

<Brief description of what this document covers.>

## <Sections...>
```

### Guidelines updates

Same approach as knowledge updates:
1. Read the full target file (or create a new one if needed)
2. Find the appropriate section
3. Add the prescriptive pattern with code examples where relevant
4. Add a source marker: `<!-- Extracted from specs/<spec-name> on YYYY-MM-DD -->`
4. Add a source marker: `<!-- Extracted from specs/archive/<spec-name> on YYYY-MM-DD -->`

If creating a new guidelines file, follow the standard structure:
```markdown
Expand Down
2 changes: 1 addition & 1 deletion commands/prep.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -67,7 +67,7 @@ Inspect `$ARGUMENTS`. The check is **only meaningful when the user provided a su

1. **`$ARGUMENTS` contains one or more URLs** (links to a Notion / Confluence / Google Doc / GitHub issue / Linear ticket / shared Markdown / PDF). Treat each URL as a likely PRD location. **Run the check.**
2. **`$ARGUMENTS` itself looks like a detailed PRD** — multiple paragraphs with structure such as headings, bullet lists of requirements, explicit goals/non-goals, acceptance criteria, or > ~400 characters of substantive description. **Run the check.**
3. **`$ARGUMENTS` is a one-line description, vague brief, or empty.** **Skip the check** — there is no source-of-truth document to align against. Write a short note in your final summary stating you skipped this phase and why, and proceed to Completion.
3. **`$ARGUMENTS` is a one-line description, vague brief, or empty.** **Skip the check** — there is no source-of-truth document to align against. Write a short note in your final summary stating you skipped this phase and why, and proceed to Completion. If the input is short (under ~400 characters) but still carries substantive, requirement-bearing detail, use your judgment and treat it as a PRD under rule 2 rather than skipping.

#### 5b. Resolve the source-of-truth PRD

Expand Down