cfsa-antigravity 1.0.0

package/template/.agent/skills/verification-before-completion/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: verification-before-completion
+description: "Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evide..."
+risk: unknown
+source: community
+date_added: "2026-02-27"
+---
+
+# Verification Before Completion
+
+## Overview
+
+Claiming work is complete without verification is dishonesty, not efficiency.
+
+**Core principle:** Evidence before claims, always.
+
+**Violating the letter of this rule is violating the spirit of this rule.**
+
+## The Iron Law
+
+```
+NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+```
+
+If you haven't run the verification command in this message, you cannot claim it passes.
+
+## The Gate Function
+
+```
+BEFORE claiming any status or expressing satisfaction:
+
+1. IDENTIFY: What command proves this claim?
+2. RUN: Execute the FULL command (fresh, complete)
+3. READ: Full output, check exit code, count failures
+4. VERIFY: Does output confirm the claim?
+   - If NO: State actual status with evidence
+   - If YES: State claim WITH evidence
+5. ONLY THEN: Make the claim
+
+Skip any step = lying, not verifying
+```
+
+## Common Failures
+
+| Claim | Requires | Not Sufficient |
+|-------|----------|----------------|
+| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
+| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
+| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
+| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
+| Regression test works | Red-green cycle verified | Test passes once |
+| Agent completed | VCS diff shows changes | Agent reports "success" |
+| Requirements met | Line-by-line checklist | Tests passing |
+
+## Red Flags - STOP
+
+- Using "should", "probably", "seems to"
+- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
+- About to commit/push/PR without verification
+- Trusting agent success reports
+- Relying on partial verification
+- Thinking "just this once"
+- Tired and wanting work over
+- **ANY wording implying success without having run verification**
+
+## Rationalization Prevention
+
+| Excuse | Reality |
+|--------|---------|
+| "Should work now" | RUN the verification |
+| "I'm confident" | Confidence ≠ evidence |
+| "Just this once" | No exceptions |
+| "Linter passed" | Linter ≠ compiler |
+| "Agent said success" | Verify independently |
+| "I'm tired" | Exhaustion ≠ excuse |
+| "Partial check is enough" | Partial proves nothing |
+| "Different words so rule doesn't apply" | Spirit over letter |
+
+## Key Patterns
+
+**Tests:**
+```
+✅ [Run test command] [See: 34/34 pass] "All tests pass"
+❌ "Should pass now" / "Looks correct"
+```
+
+**Regression tests (TDD Red-Green):**
+```
+✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
+❌ "I've written a regression test" (without red-green verification)
+```
+
+**Build:**
+```
+✅ [Run build] [See: exit 0] "Build passes"
+❌ "Linter passed" (linter doesn't check compilation)
+```
+
+**Requirements:**
+```
+✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
+❌ "Tests pass, phase complete"
+```
+
+**Agent delegation:**
+```
+✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
+❌ Trust agent report
+```
+
+## Why This Matters
+
+From 24 failure memories:
+- your human partner said "I don't believe you" - trust broken
+- Undefined functions shipped - would crash
+- Missing requirements shipped - incomplete features
+- Time wasted on false completion → redirect → rework
+- Violates: "Honesty is a core value. If you lie, you'll be replaced."
+
+## When To Apply
+
+**ALWAYS before:**
+- ANY variation of success/completion claims
+- ANY expression of satisfaction
+- ANY positive statement about work state
+- Committing, PR creation, task completion
+- Moving to next task
+- Delegating to agents
+
+**Rule applies to:**
+- Exact phrases
+- Paraphrases and synonyms
+- Implications of success
+- ANY communication suggesting completion/correctness
+
+## The Bottom Line
+
+**No shortcuts for verification.**
+
+Run the command. Read the output. THEN claim the result.
+
+This is non-negotiable.
+
+## When to Use
+This skill is applicable to execute the workflow or actions described in the overview.

package/template/.agent/skills/workflow-automation/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: workflow-automation
+description: "Workflow automation is the infrastructure that makes AI agents reliable. Without durable execution, a network hiccup during a 10-step payment flow means lost money and angry customers. With it, wor..."
+risk: unknown
+source: "vibeship-spawner-skills (Apache 2.0)"
+date_added: "2026-02-27"
+---
+
+# Workflow Automation
+
+You are a workflow automation architect who has seen both the promise and
+the pain of these platforms. You've migrated teams from brittle cron jobs
+to durable execution and watched their on-call burden drop by 80%.
+
+Your core insight: Different platforms make different tradeoffs. n8n is
+accessible but sacrifices performance. Temporal is correct but complex.
+Inngest balances developer experience with reliability. There's no "best" -
+only "best for your situation."
+
+You push for durable execution 
+
+## Capabilities
+
+- workflow-automation
+- workflow-orchestration
+- durable-execution
+- event-driven-workflows
+- step-functions
+- job-queues
+- background-jobs
+- scheduled-tasks
+
+## Patterns
+
+### Sequential Workflow Pattern
+
+Steps execute in order, each output becomes next input
+
+### Parallel Workflow Pattern
+
+Independent steps run simultaneously, aggregate results
+
+### Orchestrator-Worker Pattern
+
+Central coordinator dispatches work to specialized workers
+
+## Anti-Patterns
+
+### ❌ No Durable Execution for Payments
+
+### ❌ Monolithic Workflows
+
+### ❌ No Observability
+
+## ⚠️ Sharp Edges
+
+| Issue | Severity | Solution |
+|-------|----------|----------|
+| Issue | critical | # ALWAYS use idempotency keys for external calls: |
+| Issue | high | # Break long workflows into checkpointed steps: |
+| Issue | high | # ALWAYS set timeouts on activities: |
+| Issue | critical | # WRONG - side effects in workflow code: |
+| Issue | medium | # ALWAYS use exponential backoff: |
+| Issue | high | # WRONG - large data in workflow: |
+| Issue | high | # Inngest onFailure handler: |
+| Issue | medium | # Every production n8n workflow needs: |
+
+## Related Skills
+
+Works well with: `multi-agent-orchestration`, `agent-tool-builder`, `backend`, `devops`
+
+## When to Use
+This skill is applicable to execute the workflow or actions described in the overview.

package/template/.agent/workflows/audit-ambiguity-execute.md

@@ -0,0 +1,165 @@
+---
+description: Execute the audit one document at a time, compile report, remediate gaps, and propose next steps for the audit-ambiguity workflow
+parent: audit-ambiguity
+shard: execute
+standalone: true
+position: 2
+pipeline:
+  position: utility
+  stage: quality-gate
+  predecessors: [audit-ambiguity-rubrics]
+  successors: []
+  skills: [resolve-ambiguity, technical-writer]
+  calls-bootstrap: false
+---
+
+# Ambiguity Audit — Execute
+
+Audit each document one at a time, compile the report, remediate gaps, and propose next steps.
+
+**Prerequisite**: Read `docs/audits/audit-scope.md` to determine which layers and documents to audit. If this file does not exist, run `/audit-ambiguity-rubrics` first to determine scope and persist it.
+
+---
+
+## 0. Load Rubrics from Scope File
+
+Re-read `docs/audits/audit-scope.md` (already required by the prerequisite above). Locate the `## Rubric Files` section and load each listed rubric file by its exact path.
+
+Do **not** infer rubric paths from layer names — use only what is persisted in `audit-scope.md`.
+
+> If `docs/audits/audit-scope.md` does not contain a `## Rubric Files` section, the scope file was generated by an older version of the rubrics shard. Re-run `/audit-ambiguity-rubrics` to regenerate `audit-scope.md` with rubric paths included before continuing.
+
+---
+
+## 3. Session Independence Check
+
+Before any auditing begins, read `docs/audits/audit-scope.md` and look for a `## Gaps Fixed` section.
+
+- **If the section is absent** — This is a first run or a clean slate. Proceed to Step 3a.
+- **If the section is present** — A prior session remediated gaps. Read the `layer`, `fixed_at`, and `fixed_by_session` fields. You MUST explicitly acknowledge: *"I am auditing remediated work from session `[fixed_by_session]` that ran at `[fixed_at]`. I am a different invocation and did not perform those fixes."* If you cannot make that acknowledgment in good faith (because you are the same session/invocation that produced the `## Gaps Fixed` entry), you MUST stop immediately and instruct the user: *"The session that fixed gaps cannot grade its own homework. Please re-run `/audit-ambiguity [layer]` as a fresh invocation."*
+
+---
+
+## 3a. Implementer Simulation
+
+Read .agent/skills/verification-before-completion/SKILL.md and follow its methodology.
+
+**CRITICAL ANTI-HALLUCINATION RULE**: You MUST NOT read all documents at once. You must process one document at a time through 3a → 3b → 3c before moving to the next document. Failure to follow this one-by-one sequence guarantees hallucinated citations and audit failure.
+
+*This is the most important step. It forces the agent to encounter the spec the way an implementer would, not the way a reviewer would.*
+
+For each document:
+
+1. **Read** — Use a file reading tool to read the entire document end-to-end. Do not score yet.
+2. **Stub** — Attempt to write a stub implementation of each feature/endpoint/component using only what's in the spec — no external context or prior project knowledge.
+3. **Enumerate gaps** — List every decision you had to make that isn't explicitly specified: enum values, defaults, timeouts, error messages, retry counts, field types, HTTP status codes, validation rules, rate limit numbers, role permission lists, etc.
+4. **Write unconditionally** — Write each such decision immediately to `docs/audits/[layer]-ambiguity-report.md` as a punch list item with severity ❌.
+
+These gaps are **unconditional** — the rubric in 3b cannot override them.
+
+---
+
+## 3b. Rubric Scoring with Two-Implementer Test
+
+Score each dimension using the rubric files loaded in Step 0 (persisted paths from `docs/audits/audit-scope.md`). Read `.agent/skills/pipeline-rubrics/SKILL.md` for the scoring methodology. For every score:
+
+- **✅** → State explicitly: *"Two implementers would make the same decision because: [specific reason citing exact text from the document]."* If you cannot complete this sentence confidently, score ⚠️ instead. The bar is "unambiguous to any implementer reading cold", not "text exists somewhere."
+- **⚠️** → Quote what exists AND state precisely what is missing AND what decision an implementer would have to make without it.
+- **❌** → List the section headings checked and confirm the content is absent.
+
+**Classify gaps** (BE/FE only) — Determine if each ⚠️/❌ is a local gap or upstream dependency.
+
+> **Write immediately**: After finalizing this document's scores, write the complete score table and all citations/gap descriptions to `docs/audits/[layer]-ambiguity-report.md` (create if absent, append if present). Do not accumulate scores in context.
+
+---
+
+## 3c. Devil's Advocate Pass
+
+After scoring all dimensions for a document:
+
+1. For each ✅, ask: *"What would a junior developer get wrong about this?"* and *"What would a malicious implementer exploit in this?"*
+2. If either question reveals a gap → downgrade to ⚠️ and add the gap to the punch list.
+3. Document the devil's advocate finding alongside the score in the report.
+
+---
+
+## 3.5. Cross-Layer Consistency Check
+
+This step runs after all per-document scoring is complete, whenever the audit scope includes BE, FE, or `all`.
+
+| Check | How to Verify |
+|---|---|
+| IA → BE coverage | For each user flow in each IA shard, verify a BE endpoint exists that handles it. For each BE endpoint, verify it traces to an IA user flow. Orphan endpoints or uncovered flows are ❌. |
+| BE → FE field mapping | For each BE response field, verify at least one FE component prop consumes it. For each FE component prop, verify it maps to a BE response field. Unmapped fields or props are ❌. |
+| IA → FE access control | For each access control rule in each IA shard, verify the FE spec has corresponding conditional rendering. Missing conditional rendering is ❌. |
+| Error code coverage | For each BE error code, verify the FE spec has a corresponding error state. Missing error states are ❌. |
+
+Write all cross-layer gaps to `docs/audits/[layer]-ambiguity-report.md` as ❌ items in a `## Cross-Layer Consistency` section.
+
+## 4. Compile report summary
+
+The per-document scores and citations were written progressively during Step 3. Now add the summary section to `docs/audits/[layer]-ambiguity-report.md`:
+
+- Overall ambiguity percentage (calculated from all per-document scores)
+- Prioritized punch list (all ⚠️ and ❌ items sorted by severity)
+- Upstream dependency gaps (for Architecture/BE/FE)
+
+Do not re-read documents to reconstruct scores — read the report file that was built in Step 3.
+
+## 5. Remediate gaps (mandatory — execute automatically after Step 4)
+
+Do NOT stop and ask the user what to do. After compiling the report in Step 4, immediately execute this step for every ⚠️ and ❌ in the punch list.
+
+1. Read `.agent/skills/resolve-ambiguity/SKILL.md` and execute the resolution process inline — do not invoke it as a separate command.
+2. For each gap, classify using the skill's two-path model:
+   - **Judgment calls** (Intent/Choice gaps — no source has the answer): present to user with smart options ordered by recommendation; wait for user decision before applying any fix.
+   - **Mechanical fixes** (Technical/Factual gaps — answer exists in project docs, architecture files, upstream specs, or official sources): propose the fix with source citation; apply after user approval.
+3. Resolve judgment calls first — they may change what mechanical fixes are needed.
+4. Present findings organized by type: judgment calls first, mechanical fixes second.
+5. Apply all approved fixes to the relevant spec documents.
+6. After all fixes are applied, proceed to Step 5a to persist re-verification metadata before proposing next steps.
+
+> **Fresh-run rule**: The session that fixed gaps cannot be the session that passes them. The agent that fixed the gaps cannot grade its own homework.
+
+## 5a. Persist Re-Verification Metadata
+
+Immediately after all remediation fixes from Step 5 are applied, append or update a `## Gaps Fixed` section in `docs/audits/audit-scope.md` with the following structure:
+
+```markdown
+## Gaps Fixed
+
+- **layer**: [layer that was remediated, e.g. `vision`, `architecture`, `ia`, `be`, `fe`]
+- **fixed_at**: [ISO 8601 timestamp of when fixes were applied]
+- **fixed_by_session**: [a short identifier for this session/invocation, e.g. the conversation ID or a generated UUID]
+- **gaps_resolved**: [count of ⚠️ and ❌ items that were resolved]
+- **report_file**: [path to the ambiguity report, e.g. `docs/audits/ia-ambiguity-report.md`]
+```
+
+If a `## Gaps Fixed` section already exists, **replace it** with the current run's data (only the most recent remediation matters for the session independence check).
+
+This section is consumed by **Step 3 (Session Independence Check)** in subsequent audit runs. Both producer (here) and consumer (Step 3) use the section name `## Gaps Fixed` and the field names `layer`, `fixed_at`, `fixed_by_session`, `gaps_resolved`, `report_file`.
+
+## 6. Propose next steps
+
+Use `notify_user` to present the audit report.
+
+### If gaps were found:
+After completing remediation in Step 5, propose: "Next: Re-run `/audit-ambiguity [layer]` as a fresh invocation. The session that fixed gaps cannot grade its own homework."
+
+> **If the audit reveals a missing feature** (not just an underspecified one): Use `/evolve-feature` rather than `/resolve-ambiguity`. `/resolve-ambiguity` resolves ambiguity in existing content; `/evolve-feature` is for genuinely new capabilities that were never captured in the specs.
+
+### If ambiguity is 0%:
+
+> **Passing criteria**: A layer passes the ambiguity gate ONLY when ALL THREE conditions are met:
+> 1. **Fresh run** — This must be a clean invocation, NOT a re-check within the same session that fixed gaps. The agent that fixed the gaps cannot grade its own homework.
+> 2. **0% score** — No ⚠️ or ❌ on any dimension across all documents in the layer.
+> 3. **User confirmation** — The user explicitly confirms they have nothing else to add. The audit only checks what's written against the rubric — it cannot know about features or edge cases the user hasn't mentioned yet.
+
+If all three conditions are met, propose the next pipeline step:
+- **Vision audit passed** → "Vision is clean and confirmed. Next: Run `/create-prd` to design the architecture"
+- **Architecture audit passed** → "Architecture is clean and confirmed. Next: Run `/decompose-architecture` to create IA shards"
+- **IA audit passed** → "IA layer is clean and confirmed. Next: Run `/write-be-spec` for the first IA shard that needs a BE spec"
+- **BE audit passed** → "BE layer is clean and confirmed. Next: Run `/write-fe-spec` for the first BE spec that needs an FE spec"
+- **FE audit passed** → "FE layer is clean and confirmed. Next: Run `/plan-phase` to create implementation slices"
+
+If the user wants to add something despite 0% score, incorporate their additions into the relevant documents and re-run the audit as a fresh invocation.

package/template/.agent/workflows/audit-ambiguity-rubrics.md

@@ -0,0 +1,83 @@
+---
+description: Scope determination, document loading, and scoring rubrics for all 5 pipeline layers for the audit-ambiguity workflow
+parent: audit-ambiguity
+shard: rubrics
+standalone: true
+position: 1
+pipeline:
+  position: utility
+  stage: quality-gate
+  predecessors: []
+  successors: [audit-ambiguity-execute]
+  skills: [pipeline-rubrics]
+  calls-bootstrap: false
+---
+
+# Ambiguity Audit — Rubrics
+
+Determine audit scope, load source documents, and apply the scoring rubrics for each pipeline layer.
+
+**Prerequisite**: At least one pipeline layer must have completed documents to audit. If no documents exist, tell the user which pipeline steps to run first.
+
+---
+
+## 1. Determine audit scope
+
+Ask the user:
+- `vision` — Audit vision document only
+- `architecture` — Audit architecture design only
+- `ia` — Audit IA shards only
+- `be` — Audit BE specs only
+- `fe` — Audit FE specs only
+- `all` — Full cascade (Vision → Architecture → IA → BE → FE)
+
+## 2. Load source documents
+
+Read `.agent/skills/pipeline-rubrics/references/scoring.md` for the document-to-layer mapping table. Load all documents for each layer being audited.
+
+## 2.5. Persist audit scope
+
+Write `docs/audits/audit-scope.md` with the determined scope and document list:
+
+```markdown
+# Audit Scope
+
+> Generated: [date]
+
+## Layers to Audit
+[list of selected layers]
+
+## Documents to Audit
+[for each layer, list the exact file paths that will be audited]
+
+## Rubric Files
+[for each layer being audited, list the exact path of the rubric file]
+- vision: .agent/skills/pipeline-rubrics/references/vision-rubric.md
+- architecture: .agent/skills/pipeline-rubrics/references/architecture-rubric.md
+- ia: .agent/skills/pipeline-rubrics/references/ia-rubric.md
+- be: .agent/skills/pipeline-rubrics/references/be-rubric.md
+- fe: .agent/skills/pipeline-rubrics/references/fe-rubric.md
+
+## Status
+in-progress
+```
+
+(Only include the rubric file entries for the layers actually being audited — not all five every time. This mirrors the conditional behaviour already applied to `## Documents to Audit`.)
+
+This file is read by `/audit-ambiguity-execute` as its prerequisite.
+
+## 3. Load and apply rubrics
+
+Read `.agent/skills/pipeline-rubrics/SKILL.md` for the scoring methodology. For each layer being audited, load the matching rubric from the skill's `references/` directory:
+
+| Layer | Rubric File |
+|-------|-------------|
+| Vision | `.agent/skills/pipeline-rubrics/references/vision-rubric.md` |
+| Architecture | `.agent/skills/pipeline-rubrics/references/architecture-rubric.md` |
+| IA | `.agent/skills/pipeline-rubrics/references/ia-rubric.md` |
+| BE | `.agent/skills/pipeline-rubrics/references/be-rubric.md` |
+| FE | `.agent/skills/pipeline-rubrics/references/fe-rubric.md` |
+
+Apply the scoring formula from `.agent/skills/pipeline-rubrics/references/scoring.md`.
+
+Proceed to `/audit-ambiguity-execute` with scope and rubrics loaded.

package/template/.agent/workflows/audit-ambiguity.md

@@ -0,0 +1,64 @@
+---
+description: Measure coverage and ambiguity across all pipeline layers (Vision, Architecture, IA, BE, FE) with scored reports
+pipeline:
+  position: utility
+  stage: quality-gate
+  predecessors: [] # callable from any stage
+  successors: [] # returns to caller
+  skills: [resolve-ambiguity, code-review-pro, technical-writer]
+  calls-bootstrap: false
+shards: [audit-ambiguity-rubrics, audit-ambiguity-execute]
+---
+
+# Ambiguity Audit
+
+Audit pipeline output completeness and identify gaps that would force guesswork during implementation.
+
+**Usage**: `/audit-ambiguity` — you'll be asked which layer(s) to audit.
+
+---
+
+## 0. Load audit skills
+
+Read these skills for review guidance:
+1. `.agent/skills/code-review-pro/SKILL.md` — Review methodology
+2. `.agent/skills/technical-writer/SKILL.md` — Spec clarity standards
+
+---
+
+## Shard Overview
+
+| # | Shard | What It Does |
+|---|-------|-------------|
+| 1 | [`audit-ambiguity-rubrics`](.agent/workflows/audit-ambiguity-rubrics.md) | Determines scope, loads documents, provides all 5 rubrics (Vision, Architecture, IA, BE, FE) with scoring criteria |
+| 2 | [`audit-ambiguity-execute`](.agent/workflows/audit-ambiguity-execute.md) | Executes the audit one document at a time, compiles report, remediates gaps, proposes next steps |
+
+---
+
+## Orchestration
+
+### Step A — Run `.agent/workflows/audit-ambiguity-rubrics.md`
+
+Asks the user which layer(s) to audit, loads the source documents, and provides the scoring rubrics for each applicable layer.
+
+### Step B — Run `.agent/workflows/audit-ambiguity-execute.md`
+
+Audits each document one at a time (read → score with evidence → classify gaps → verify → finalize), compiles the report to `docs/audits/`, remediates gaps using `resolve-ambiguity`, and proposes next steps.
+
+---
+
+## Key Principles
+
+- **One document at a time** — Read, score, verify, finalize. Never batch-read and score from memory.
+- **Every score needs evidence** — A ✅ without a citation is lazy. A ❌ without listing what you searched is a potential hallucination.
+- **Verify before finalizing** — Re-read with findings in hand. This is the hallucination catch.
+- **Read the full document** — Don't skim. Ambiguity hides in the details.
+- **Be specific** — "Error handling incomplete" is not a finding. "POST /v1/reviews has no error code for duplicate review" IS a finding.
+- **Open questions ≠ ambiguity** — Explicitly flagged unknowns are known unknowns, not gaps.
+- **Score honestly** — The goal is to find real gaps, not to produce a good number.
+- **Upstream first** — Fix Vision gaps before Architecture, Architecture before IA, IA before BE, BE before FE.
+- **Resolve, don't just report** — Use `resolve-ambiguity` to classify and fix gaps, not just list them.
+- **Simulate before scoring** — Before scoring any document, attempt to write a stub implementation from it. Every decision you have to make that isn't explicitly specified is a gap. Add it to the punch list unconditionally.
+- **Two-implementer test** — A ✅ means two different developers reading only this spec would make the same implementation decision. If you cannot confidently say that, score ⚠️ instead.
+- **Devil's advocate pass** — After scoring, argue against each ✅. Ask: "What would a junior developer get wrong?" and "What would a malicious implementer exploit?" Any ✅ that can't survive this drops to ⚠️.
+- **Cross-layer gaps are ❌** — A BE spec that doesn't match its IA shard user flows fails regardless of its individual score. Cross-layer consistency is checked after per-document scoring.