Skip to content

Gather Inputs

ContributorsPaul Atkins

Purpose

Collect, validate, and document all inputs needed before running a gap analysis or remediation plan. This skill ensures:

  1. Every input is documented — what it is, where it came from, when it was last updated.
  2. Inputs are cross-referenced — inconsistencies between documents are surfaced.
  3. Superseded information is detected — newer sources override older ones.
  4. The source of truth is explicit for every fact.
  5. Unknowns are flagged with a recommended action (collect, assume, or escalate to HITL).

Why this matters

Gap analyses and plans built on inconsistent or stale inputs produce findings that look authoritative but are wrong. Errors introduced at the input stage compound through every downstream document. This skill is the first line of defence.

Prerequisites

None — this is the starting skill in the SoW workflow.

Instructions

Step 1 — Collect input documents

Ask the user for the following categories. Record what is provided and what is missing.

# Category What to collect Required?
1 System description Name, purpose, deployment model, tech stack, size Yes
2 Architecture documentation Design doc, README, diagrams Yes (or codebase access)
3 Target state / reference patterns Reference repos, checklists, standards Yes
4 Codebase access Direct access, doc-only, or business user proxy Yes
5 Organisational context CI/CD platform, tiering, TDA, provisioning, change management Yes
6 Templates and blueprints Existing SoW, pipeline YAML, IaC templates, skills library Optional

Step 2 — Build the input register

For every fact collected, create an entry in the input register:

## Input Register

| # | Fact | Value | Source | Source date | Confidence | Notes |
|---|------|-------|--------|------------|------------|-------|
| 1 | Tech stack — backend | Python 3.13, FastAPI 0.136 | Architecture doc v2.1 | 2026-06-15 | High | Confirmed by pyproject.toml |
| 2 | Database | SQLite WAL, 9.2 GB | Architecture doc v2.1 | 2026-06-15 | Medium | Size from doc; not verified against live DB |
| 3 | Test count | 213 backend, 1 frontend | Technical supplement | 2026-06-20 | High | Supersedes arch doc claim of "comprehensive tests" |
| 4 | CI/CD platform | GitHub Actions | README | Unknown | Low | No pipeline YAML found in repo |

Confidence levels:

Level Meaning
High Verified against code or live system
Medium Stated in documentation, not independently verified
Low Inferred, assumed, or from a potentially stale source
Unknown No data available — requires collection or HITL decision

Step 3 — Cross-reference for inconsistencies

Compare facts across all input sources. For each inconsistency:

## Inconsistencies

| # | Fact | Source A says | Source B says | Resolution | Status |
|---|------|-------------|-------------|------------|--------|
| 1 | Python version | Arch doc: 3.11 | pyproject.toml: 3.13 | pyproject.toml is source of truth (code > docs) | Resolved |
| 2 | Test coverage | README: "90%+" | coverage.xml: 67% | coverage.xml is source of truth (measured > claimed) | Resolved |
| 3 | Auth method | Arch doc: "Basic auth" | Supplement: "No auth" | Unknown — flag for HITL | **Open** |

Resolution priority (most authoritative → least):

  1. Live system / running code output
  2. Code files (pyproject.toml, Dockerfile, package.json)
  3. CI/CD pipeline YAML
  4. Technical supplement (codebase-derived)
  5. Architecture document
  6. README
  7. Verbal/chat statements

Step 4 — Detect superseded information

When a newer source provides updated data for a fact already recorded:

  1. Mark the older entry as superseded in the input register.
  2. Record the new value with its source and date.
  3. Add to the inconsistencies table if the values conflict.
  4. Note the supersession in the register's Notes column.

Example: 

| 5 | Endpoint count | 143 | Technical supplement | 2026-06-20 | High | Supersedes arch doc estimate of "~100" |

Step 5 — Flag unknowns and recommend actions

For every fact with confidence "Low" or "Unknown", recommend one of:

Action When to use
Collect Data exists but hasn't been provided — create a follow-up request
Assume Data doesn't exist or can't be obtained — state the assumption explicitly with "Impact if Wrong"
Escalate Multiple valid interpretations exist — present options to the user for a HITL decision 
## Unknowns Requiring Decisions

| # | Fact | Current state | Recommended action | Options (if escalate) |
|---|------|--------------|-------------------|----------------------|
| 1 | Database migration target | Not discussed | Escalate | (a) PostgreSQL, (b) Cosmos DB, (c) Stay SQLite |
| 2 | Concurrent user count | Not stated | Assume 5 | Impact if wrong: infrastructure sizing may need revision |
| 3 | Streamlit dependency purpose | Unclear | Collect | Add to follow-up request |

Step 6 — Produce the input summary for HITL Gate 1

Present the consolidated summary to the user:

Here's what I'm working with. Please confirm or correct:

**System:** [name] — [description]
**Current state source:** [doc name / codebase access / both]
**Target standard:** [reference repos / checklist / skills]
**Codebase access:** [direct / doc-only / business user proxy]
**Org context:** [CI platform, tiering, TDA, provisioning model]
**Templates:** [what was provided]

**Input register:** [N] facts recorded, [M] high confidence, [P] medium, [Q] low/unknown
**Inconsistencies found:** [count] — [resolved count] resolved, [open count] open
**Unknowns requiring your decision:** [count]

[List each open inconsistency and unknown with options]

I need these resolved before starting the gap analysis. Errors here
will compound through every downstream document.

Wait for explicit approval before proceeding.

Output

The input register, inconsistencies table, and unknowns table should be included as a section in the gap analysis document (or as a standalone [system]-input-register.md if the user prefers).

Tips

  • Code beats docs. When a README says one thing and pyproject.toml says another, the code file wins.
  • Date everything. Sources without dates get low confidence by default.
  • Don't resolve ambiguity silently. If two sources disagree and neither is clearly authoritative, escalate to the user. Silent resolution is how wrong assumptions enter the system.
  • Re-run after supplement. When a technical supplement arrives, re-run Steps 3–5 against the updated input set. New data often supersedes earlier assumptions.

Troubleshooting

Error: Input register has too many "Unknown" confidence entries to proceed. Cause: Insufficient source documents were provided. Solution: Use the create-followup-request skill to generate a targeted information request. Prioritise unknowns that block Phase 0–1 plan items.

Error: Two sources contradict each other and neither is clearly authoritative. Cause: Documentation has drifted from the codebase, or multiple versions exist. Solution: Escalate to HITL. Present both values with their sources and ask the user to confirm which is correct. Do not silently resolve ambiguity.

Error: User provides verbal corrections that conflict with written documents. Cause: Written docs are stale; verbal info is more current but unverifiable. Solution: Record the verbal correction in the input register with confidence "Medium" and source "verbal — [date]". Ask the user to confirm in writing or verify against the codebase.