@caddis/cli 0.0.0 → 0.2.0

package/bundles/antigravity-plugin-extras/skills/golden-nuggets/SKILL.md

@@ -0,0 +1,192 @@
+---
+name: golden-nuggets
+description: "Extract durable tribal knowledge ('gold nuggets') from a codebase or a set of changed files and route each to its correct destination - instruction file, runbook, hub, or (in CI capture mode) a review inbox. This SKILL.md is the single source of truth for nugget categories, routing rules, write rules, inbox format, and verification gates. It is read by the knowledge-transfer agent (pipeline mode), by the /golden-nuggets prompt (independent mode), and referenced by the CI extraction script (capture mode). Use when capturing what was learned after a feature, fix, sprint, incident, or release."
+mode: agent
+tools: ['codebase', 'editFiles', 'search']
+---
+
+# Golden Nuggets - Knowledge Capture Core
+
+This skill defines what counts as a durable nugget, where it belongs, and how to write it without damaging existing docs. The same extraction logic applies in all modes, but the write target changes by mode.
+
+---
+
+## Modes
+
+| Mode | Invoked by | Judgement present? | Write target |
+|------|------------|--------------------|--------------|
+| Pipeline | `knowledge-transfer` agent at a gated stage | Yes | Live instruction files, runbooks, or the managed hub region |
+| Independent | `/golden-nuggets` prompt | Yes | Live instruction files, runbooks, or the managed hub region |
+| Capture (CI) | `extract_nuggets.ps1` in `release_metadata` | No | `.github/agent-docs/nuggets-inbox.md` only |
+
+Why this split:
+
+- Writing to a live `*.instructions.md` changes future agent behavior.
+- Pipeline and independent modes include human or agent judgement, so live writes are allowed.
+- CI capture mode has no judgement, so it may create candidates only. It must never write live instruction files, runbooks, or the hub.
+
+---
+
+## Verification Gate
+
+In pipeline and independent modes, follow this order exactly:
+
+1. Extract candidate nuggets.
+2. Route each nugget.
+3. Write each nugget to its live destination.
+4. Verify each live write landed by re-reading or searching for a distinctive phrase.
+5. Only after live writes are verified, write the session log.
+
+If you are about to update the log before any live write has been verified, stop and go back.
+
+### Completion rule
+
+Live writes are the primary deliverable outside CI mode. The stage is complete only when one of these is true:
+
+- At least one live instruction file, runbook, or managed hub region was updated and verified.
+- No durable nugget existed, and you say so explicitly.
+
+An empty "Live writes" section with no explicit "no durable nugget existed" justification means the stage failed.
+
+---
+
+## Step 1 - Detect the Tech Stack
+
+Identify the primary language/runtime, frameworks, hosting model, database or storage layer, test framework, CI/CD pipeline, and any unusual infrastructure. Use that to decide which nugget categories are relevant.
+
+---
+
+## Step 2 - Extract Gold Nuggets
+
+Before scanning, list `*.instructions.md` files in `.github/instructions/` and note their `applyTo` patterns. Extract only what is not already captured.
+
+Categories:
+
+- Environment: env var loading order, config precedence, dev-vs-prod differences, reverse proxy or IIS rules, auth handshakes, port/CORS behavior.
+- Architecture: startup sequencing, DI registration rules, multi-process coexistence, initialization rules, caching behavior.
+- UI / Embedded Frontend: iframe or postMessage contracts, lifecycle rules, z-index or positioning behavior, state rules, bug fixes that must not be reverted.
+- Data and Query Patterns: query composition, ORM or adapter quirks, cross-schema access, pooling, migration rules, externalized query rules.
+- Test and CI Patterns: fixture setup, mock conventions, test isolation, flaky-test causes, CI flags, E2E sequencing.
+- Critical Rules: conventions enforced by practice rather than lint, naming/import patterns, DRY boundaries, logging/security rules, feature-flag wiring.
+- Operational Procedures: restart sequences, deploy decision trees, incident checks, verification steps, rollback or connectivity procedures.
+
+### Capture mode input rules
+
+In CI capture mode, do not scan the full codebase. Work only from release-range commit metadata. Consider only `feat`, `fix`, `perf`, and `refactor` conventional-commit subjects. Ignore `chore`, `docs`, `style`, `test`, `build`, and `ci`.
+
+Each candidate must carry enough metadata for later review:
+
+- `fingerprint`: stable hash from the normalized commit subject
+- `source`: `ci-release-capture`
+- `shape`: `rule-shaped` or `project-local`
+- `suggested-route`: `promote-to-pool` or `keep-local`
+- `raw`: original conventional-commit subject
+- `from-commits`: one or more short shas
+
+CI produces candidates, not conclusions.
+
+---
+
+## Step 3 - Route Each Nugget
+
+Route to the most specific destination before falling back to the hub.
+
+- Instruction file: `.github/instructions/*.instructions.md` for conventions, framework rules, component rules, or scoped patterns.
+- Runbook: `docs/runbooks/` or equivalent for operational procedures.
+- Hub: `copilot-instructions.md`, but only inside the `<!-- junai:start -->` to `<!-- junai:end -->` region, and only for genuinely global context.
+
+In capture mode, "route" means tagging the candidate with `proposed-target` and `suggested-route`. CI still writes only to the inbox.
+
+### Shape tag
+
+- `rule-shaped`: generalizable pattern that may deserve promotion to the pool later.
+- `project-local`: specific to this project's wiring or infrastructure and likely to stay local.
+
+Fallback:
+
+- If no instruction files or runbooks directory exist, use the hub.
+
+---
+
+## Step 4 - Write Rules (Pipeline and Independent Modes)
+
+Write directly when:
+
+- The nugget is genuinely new.
+- The nugget adds detail without contradicting existing docs.
+
+Stop and ask before writing when:
+
+- Existing docs state a rule that the code now contradicts.
+- A documented rule appears to be intentionally worked around in several places.
+
+Never:
+
+- Delete or rewrite existing sections.
+- Remove Commands, pipeline, CI, deploy, or key-files sections.
+- Reduce existing detail.
+- Duplicate content in both the hub and a more specific instruction file or runbook.
+
+After every live write, verify it landed.
+
+---
+
+## Step 4-CI - Write Rules (Capture Mode Only)
+
+Append each candidate to `.github/agent-docs/nuggets-inbox.md`. Do not touch live instruction files, runbooks, or the hub.
+
+Inbox entry format:
+
+```md
+## CANDIDATE {iso-date} - {release-version}
+- fingerprint: {stable fingerprint derived from normalized commit subject}
+- source: ci-release-capture
+- shape: rule-shaped | project-local
+- category: {category}
+- suggested-route: keep-local | promote-to-pool
+- proposed-target: {path/to/file.instructions.md | runbook | hub}
+- from-commits: {sha7}, {sha7}
+- raw: {original conventional-commit subject}
+- nugget: {one-paragraph durable lesson, in the agent's words}
+- status: pending
+```
+
+---
+
+## Step 5 - Write Session Log (Pipeline and Independent Modes)
+
+Only after live writes are verified, prepend to `docs/gold-nuggets-log.md`:
+
+```md
+## Gold Nuggets Session - {date}
+### Added
+- {destination file} -> {section} -> {one-line summary}
+### Conflicts flagged
+- {what file said} vs {what code shows} - {resolution}
+- None
+### Skipped (nothing new)
+- {category}
+> Review/archive once verified.
+```
+
+The log records writes that happened. Capture mode does not write the log.
+
+---
+
+## Inbox Hygiene (Capture Mode)
+
+- Cap: if pending candidates are already `>= 15`, append nothing and emit `inbox full - review pending`.
+- TTL: candidates older than 14 days are discarded by the review tool, not by CI.
+- Dedup: never append a candidate whose normalized subject or fingerprint already exists in the inbox. If multiple commits in the same release range normalize to the same candidate, keep one block and merge the shas into `from-commits`.
+
+The inbox should trend toward empty rather than growing forever.
+
+---
+
+## Quick Reference
+
+```text
+/golden-nuggets               Full extraction, all categories, write live
+/golden-nuggets chat widget   Focus one area
+/golden-nuggets ops           Operational procedures / runbooks only
+```

package/bundles/antigravity-plugin-extras/skills/humanizer/SKILL.md

@@ -0,0 +1,194 @@
+---
+name: humanizer
+description: Identify and remove AI writing patterns from text to make it sound natural and human. Covers 29 documented LLM output patterns. Use when asked to humanize, de-AI, un-ChatGPT, or rewrite drafts (blogs, docs, emails, PRs, releases) to sound authentic.
+source: NousResearch/hermes-agent
+license: MIT
+---
+
+# Humanizer
+
+Remove AI-generated writing patterns and restore authentic voice. Based on Wikipedia's "Signs of AI writing" guide and Siqi Chen's original [blader/humanizer](https://github.com/blader/humanizer) (MIT).
+
+**Core insight**: LLMs guess statistically likely continuations. The result trends toward the most probable phrasing — which is how telltale patterns get baked in. Removing them is necessary but not sufficient. The output also needs personality.
+
+## When to Load
+
+- "Humanize this", "de-AI this", "un-ChatGPT this"
+- "Rewrite this to sound more natural"
+- "This sounds like it was written by AI"
+- Before publishing: blog posts, release notes, docs, emails, social posts
+- Applying to Claude's own output in a conversation
+
+## Input Methods
+
+1. **Inline** — user pastes text; rewrite in place
+2. **File** — `read_file` to load, `write_file` or `patch` to apply
+3. **Voice calibration** — user provides a writing sample to match their tone
+
+## The 29 AI Patterns
+
+### Content Patterns (1–6)
+
+**1. Undue significance/legacy emphasis**
+Watch for: "stands as," "testament to," "pivotal moment," "broader trends"
+Fix: Replace with the specific fact, not the editorial wrapper
+
+**2. Undue notability/media emphasis**
+Watch for: "cited by," "leading expert," "active on social media"
+Fix: Either state the credential specifically or cut it
+
+**3. Superficial analysis with -ing endings**
+Watch for: "highlighting," "underscoring," "reflecting," "symbolizing," "demonstrating"
+Fix: Rewrite as a direct statement of what the fact means
+
+**4. Promotional / ad-copy language**
+Watch for: "nestled," "vibrant," "breathtaking," "stunning," "renowned," "world-class"
+Fix: Describe the actual attribute instead of the adjective
+
+**5. Vague attributions / weasel words**
+Watch for: "experts argue," "industry reports suggest," "observers cite"
+Fix: Name the source or cut the attribution entirely
+
+**6. Formulaic "Challenges and Future Prospects" sections**
+Watch for: Sections that end with "Despite challenges..." followed by optimistic filler
+Fix: Either include specific named challenges or remove the section
+
+### Language & Grammar Patterns (7–13)
+
+**7. Overused AI vocabulary**
+Post-2023 words that appear far more in AI text than human text:
+`actually`, `crucial`, `delve`, `landscape`, `tapestry`, `underscore`, `interplay`, `intricacies`, `groundbreaking`, `revolutionary`, `unleash`, `game-changing`, `seamlessly`, `robust`
+Fix: Replace with plain language or cut
+
+**8. Copula avoidance** (replacing "is" with indirect constructions)
+Watch for: "serves as," "marks," "boasts," "features," "represents"
+Fix: Use "is" or rewrite directly — "X serves as a hub" → "X is a hub"
+
+**9. Negative parallelisms / tailing negations**
+Watch for: "not only...but," sentence-ending fragments like "no guessing required"
+Fix: Write complete parallel clauses
+
+**10. Rule-of-three overuse**
+Watch for: Every point being grouped into exactly three items
+Fix: Use the number the content actually requires
+
+**11. Elegant variation** (synonym substitution to avoid repetition)
+Watch for: The same concept referred to by a different word every sentence
+Fix: Repeat the word if that's what you mean — humans do this
+
+**12. False ranges**
+Watch for: "From A to B" where A and B aren't on a meaningful spectrum
+Fix: Drop the range framing; state the things directly
+
+**13. Passive voice / subjectless fragments**
+Watch for: "It was determined that," "Steps were taken to"
+Fix: Name the actor — "We determined," "The team took steps"
+
+### Style Patterns (14–19)
+
+**14. Em dash overuse**
+LLMs use "—" far more than humans. Replace with commas, periods, colons, or parentheses in most cases.
+
+**15. Overuse of boldface**
+Mechanical emphasis bolding every third concept. Remove unless the bold is doing real work.
+
+**16. Inline-header vertical lists**
+Pattern: **Bold phrase**: followed by description, repeated. Fix: Rewrite as flowing prose unless it's genuinely tabular.
+
+**17. Title Case Headings**
+Only capitalize the first word and proper nouns. Not Every Main Word.
+
+**18. Decorative emojis**
+Remove emojis from headings, bullet points, and lists unless the context requires them (Slack messages, social posts).
+
+**19. Curly quotation marks**
+Use straight quotes ("...") not curly ("...") in code contexts.
+
+### Communication Patterns (20–22)
+
+**20. Collaborative chatbot artifacts**
+Remove: "I hope this helps!", "Let me know if you need anything!", "Certainly!", "Of course!", "Great question!"
+
+**21. Knowledge-cutoff disclaimers**
+Strip: "as of my last update," "based on available information," "while I cannot verify"
+
+**22. Sycophantic / servile tone**
+Remove excessive positivity, hedging-to-please, and "let me know what you think" endings
+
+### Filler & Hedging (23–29)
+
+**23. Filler phrases**
+| Replace | With |
+|---------|------|
+| "in order to" | "to" |
+| "due to the fact that" | "because" |
+| "at this point in time" | "now" |
+| "it is important to note that" | just state the fact |
+| "please note that" | just state the fact |
+
+**24. Excessive hedging**
+"could potentially possibly be argued to suggest" → "may suggest" or just "suggests"
+
+**25. Generic positive conclusions**
+"the future looks bright" / "exciting times ahead" → state a specific fact or expectation, or cut entirely
+
+**26. Hyphenated word-pair overuse**
+`cross-functional`, `data-driven`, `client-facing`, `best-in-class` — vary usage or replace with plain language
+
+**27. Persuasive authority tropes**
+Remove: "at its core," "the real question is," "what really matters here," "the key insight is"
+
+**28. Signposting / meta-announcements**
+Cut: "let's dive in," "here's what you need to know," "without further ado," "in this article, we will"
+
+**29. Fragmented headers**
+Headers that just restate the section name as a sentence, contributing no information. Remove or make specific.
+
+## Adding Soul (Required — Not Optional)
+
+Removing AI patterns alone leaves soulless prose. Signs your rewrite is still lifeless:
+- Uniform sentence length throughout
+- No opinions, only neutral reporting
+- No acknowledgment of uncertainty or complexity
+- Missing first-person perspective where appropriate
+- No humor, specificity, or texture
+
+**How to add voice:**
+- Have opinions — react to facts, don't just present them
+- Vary rhythm — alternate short punchy sentences with longer ones
+- Acknowledge complexity — "this is messier than it sounds"
+- Use "I" where honest
+- Allow specific details — exact numbers, real names, concrete comparisons
+- Let tangents exist — a brief aside feels human
+
+## Voice Calibration (Optional)
+
+If the user provides a writing sample:
+1. Analyze: sentence length patterns, word choice register, paragraph starters, punctuation habits, recurring phrases
+2. Mirror those patterns in the rewrite
+3. Don't just remove AI patterns — replace them with patterns from the sample
+
+## Process
+
+1. Read input (use `read_file` if a file path is given)
+2. Identify all pattern instances (annotate mentally)
+3. Rewrite problematic sections
+4. Inject voice — opinions, rhythm variation, specificity
+5. Present draft rewrite
+6. Self-audit: "What still sounds AI-generated?" (brief bullets)
+7. Address remaining tells
+8. Present final version
+9. For file edits: apply with `patch` (targeted) or `write_file` (full)
+
+## Output Format
+
+```
+DRAFT REWRITE
+[rewritten text]
+
+REMAINING TELLS
+- [bullet: what still sounds AI-generated and why]
+
+FINAL REWRITE
+[final version addressing the tells]
+```

package/bundles/antigravity-plugin-extras/skills/image-enhancer/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: image-enhancer
+context: fork
+description: Improves the quality of images, especially screenshots, by enhancing resolution, sharpness, and clarity. Perfect for preparing images for presentations, documentation, or social media posts.
+---
+
+# Image Enhancer
+
+This skill takes your images and screenshots and makes them look better—sharper, clearer, and more professional.
+
+## When to Use This Skill
+
+- Improving screenshot quality for blog posts or documentation
+- Enhancing images before sharing on social media
+- Preparing images for presentations or reports
+- Upscaling low-resolution images
+- Sharpening blurry photos
+- Cleaning up compressed images
+
+## What This Skill Does
+
+1. **Analyzes Image Quality**: Checks resolution, sharpness, and compression artifacts
+2. **Enhances Resolution**: Upscales images intelligently
+3. **Improves Sharpness**: Enhances edges and details
+4. **Reduces Artifacts**: Cleans up compression artifacts and noise
+5. **Optimizes for Use Case**: Adjusts based on intended use (web, print, social media)
+
+## How to Use
+
+### Basic Enhancement
+
+```
+Improve the image quality of screenshot.png
+```
+
+```
+Enhance all images in this folder
+```
+
+### Specific Improvements
+
+```
+Upscale this image to 4K resolution
+```
+
+```
+Sharpen this blurry screenshot
+```
+
+```
+Reduce compression artifacts in this image
+```
+
+### Batch Processing
+
+```
+Improve the quality of all PNG files in this directory
+```
+
+## Example
+
+**User**: "Improve the image quality of screenshot-2024.png"
+
+**Output**:
+```
+Analyzing screenshot-2024.png...
+
+Current specs:
+- Resolution: 1920x1080
+- Format: PNG
+- Quality: Good, but slight blur
+
+Enhancements applied:
+✓ Upscaled to 2560x1440 (retina)
+✓ Sharpened edges
+✓ Enhanced text clarity
+✓ Optimized file size
+
+Saved as: screenshot-2024-enhanced.png
+Original preserved as: screenshot-2024-original.png
+```
+
+**Inspired by:** Lenny Rachitsky's workflow from his newsletter - used for screenshots in his articles
+
+## Tips
+
+- Always keeps original files as backup
+- Works best with screenshots and digital images
+- Can batch process entire folders
+- Specify output format if needed (PNG for quality, JPG for smaller size)
+- For social media, mention the platform for optimal sizing
+
+## Common Use Cases
+
+- **Blog Posts**: Enhance screenshots before publishing
+- **Documentation**: Make UI screenshots crystal clear
+- **Social Media**: Optimize images for Twitter, LinkedIn, Instagram
+- **Presentations**: Upscale images for large screens
+- **Print Materials**: Increase resolution for physical media
+

package/bundles/antigravity-plugin-extras/skills/intent-writer/SKILL.md

@@ -0,0 +1,201 @@
+---
+name: intent-writer
+description: Structure freetext ideas, backlog items, or vague requirements into a formal Intent Document that preserves user intent across the entire agent pipeline chain.
+---
+
+# Intent Writer Skill
+
+## Purpose
+
+Create an **Intent Document** — a structured, immutable artifact that captures the user's original intent for a feature or task. This document is the anchor that prevents intent drift as work passes through the agent pipeline (PRD → Architect → Plan → Implement).
+
+**Problem it solves**: In multi-agent workflows, intent, goals, and specifics get diluted with each handoff. By the time an implementing agent receives work, the original intent may be distorted or lost entirely. The Intent Document gives every agent in the chain direct access to the original intent.
+
+---
+
+## When to Use
+
+- A user provides a vague idea, freetext request, or rough notes
+- Before handing work to the PRD agent
+- When the `@prompt-engineer` agent is refining input for the pipeline
+- When pulling a backlog item into active work
+- To create an Intent Amendment when requirements change mid-pipeline
+
+---
+
+## Steps
+
+### Step 1: Read Project Context
+
+1. Read `project-config.md` → identify tech stack, framework, deployment constraints
+2. Scan `agent-docs/intents/` → check for existing intents on the same topic (avoid duplicates)
+3. If this is an amendment, read the original Intent Document being amended
+
+### Step 2: Extract Intent from User Input
+
+From whatever input is provided (freetext, idea, backlog item, conversation), extract:
+
+| Field | What to capture |
+|-------|----------------|
+| **Goal** | What the user wants to achieve — the "why" and "what", not the "how" |
+| **Success Criteria** | Testable conditions that define "done" — concrete, measurable |
+| **Constraints** | Technical limitations, business rules, framework restrictions, deployment constraints |
+| **Out of Scope** | What this is specifically NOT — prevents scope creep |
+| **Original User Input** | Verbatim preservation of the user's words — no agent can claim they didn't know |
+
+### Step 3: Framework Feasibility Pre-Check
+
+Before finalizing the Intent Document, cross-reference the goal against `project-config.md` → Tech Stack:
+
+- Does the goal involve UI? → Check if the proposed approach is feasible in the target framework
+- Does the goal involve data? → Check if the database type supports what's needed
+- Does the goal involve deployment? → Check if the deployment environment allows what's needed
+- Does the goal involve external services? → Check air-gapped deployment constraints
+
+If a feasibility issue is found:
+1. Add it to the **Constraints** section explicitly
+2. Note it in the **Feasibility Warnings** field
+3. Suggest alternatives if applicable
+
+### Step 4: Generate chain_id
+
+Create a unique identifier for this feature chain:
+- Format: `FEAT-YYYY-MMDD-{slug}`
+- Example: `FEAT-2026-0218-chat-widget`
+- The slug should be 2-4 words, hyphenated, describing the feature
+- Check `agent-docs/ARTIFACTS.md` to ensure the chain_id isn't already in use
+
+### Step 5: Write the Intent Document
+
+Create the document at `agent-docs/intents/{chain_id}.md`:
+
+Apply `.github/instructions/document-frontmatter.instructions.md` when creating or updating the Intent Document. The YAML frontmatter block must be the first content in the file. New intent documents require `Original Author`, `Creation Date`, and `Creating Model`; revised intent documents must preserve those fields and add or update `Last Author`, `Last Updated`, and `Last Model Used`.
+
+```markdown
+---
+agent: prompt-engineer
+created: {YYYY-MM-DDTHH:MM:SSZ}
+status: current
+type: intent
+chain_id: {FEAT-YYYY-MMDD-slug}
+approval: pending
+feasibility_warnings: {list or "none"}
+Original Author: prompt-engineer
+Creation Date: {YYYY-MM-DDTHH:MM:SSZ}
+Creating Model: {exact runtime model identifier or display name}
+---
+<!-- AGENT-GENERATED: This Intent Document preserves user intent for the agent pipeline.
+     Every agent in the chain MUST read this document FIRST before processing. -->
+
+# Intent: {Feature Title}
+
+## Goal
+{Clear statement of what the user wants to achieve}
+
+## Success Criteria
+- {Testable criterion 1}
+- {Testable criterion 2}
+- {Testable criterion 3}
+
+## Constraints
+- {Technical constraint}
+- {Business constraint}
+- {Framework constraint — from feasibility check}
+
+## Out of Scope
+- {Explicitly excluded item 1}
+- {Explicitly excluded item 2}
+
+## Feasibility Notes
+{Any warnings from the framework feasibility check, or "No feasibility issues identified."}
+
+## Original User Input
+> {Copy the user's original input verbatim here — preserve exact wording}
+```
+
+### Step 6: Update Manifest
+
+Add a row to `agent-docs/ARTIFACTS.md`:
+
+| Date | Agent | Type | Description | Path | Status | Approval | Chain ID |
+|------|-------|------|-------------|------|--------|----------|----------|
+| {date} | prompt-engineer | intent | {Feature title} | agent-docs/intents/{chain_id}.md | current | pending | {chain_id} |
+
+### Step 7: Report
+
+Tell the user:
+- Intent Document created at `agent-docs/intents/{chain_id}.md`
+- Summary: Goal, key constraints, feasibility warnings (if any)
+- Next step: "Review and approve the Intent Document. Once approved, this can be handed to the PRD agent."
+- The `chain_id` for future reference
+
+---
+
+## Intent Amendments
+
+When requirements change mid-pipeline:
+
+### When to Create an Amendment (not a new Intent)
+
+- The original goal is the same but specifics changed
+- A constraint was added or removed
+- Success criteria changed
+- The user said "actually, I want X instead of Y" for part of the feature
+
+### When to Create a New Intent
+
+- The goal itself is fundamentally different
+- The user is starting a different feature entirely
+
+### Amendment Process
+
+1. Create an amendment document at `agent-docs/intents/{chain_id}-amendment-{N}.md`:
+
+```markdown
+---
+agent: prompt-engineer
+created: {YYYY-MM-DDTHH:MM:SSZ}
+status: current
+type: intent-amendment
+chain_id: {same chain_id as original}
+amends: agent-docs/intents/{chain_id}.md
+amendment_number: {N}
+approval: pending
+Original Author: prompt-engineer
+Creation Date: {YYYY-MM-DDTHH:MM:SSZ}
+Creating Model: {exact runtime model identifier or display name}
+---
+
+# Intent Amendment #{N}: {Brief description of change}
+
+## What Changed
+- {Specific change 1}
+- {Specific change 2}
+
+## Why
+{Reason for the change}
+
+## Impact Assessment
+- **PRD**: {Does PRD need updating? Which sections?}
+- **Architecture**: {Does architecture need updating?}
+- **Plan**: {Does plan need updating? Which phases?}
+- **Implementation**: {Is any completed work affected?}
+
+## Downstream Artifacts to Supersede
+- {List artifact paths that are now stale due to this change}
+```
+
+2. Mark downstream artifacts (produced BEFORE the amendment) as `superseded` in the manifest
+3. The pipeline re-runs from the earliest affected point
+
+If you revise an existing intent or amendment file instead of creating a new one, preserve the original metadata fields and add or update `Last Author`, `Last Updated`, and `Last Model Used` using full ISO 8601 UTC timestamps.
+
+---
+
+## Important Notes
+
+- Intent Documents are **effectively immutable** — once created, they're a historical record of what was agreed
+- Changes go through the Amendment process, not by editing the original
+- Every agent in the pipeline MUST read the Intent Document (and any amendments) FIRST
+- The `chain_id` links all artifacts in the feature chain — always carry it through
+- Original User Input is preserved verbatim — this is the ultimate source of truth