migrate-legacy-acs-to-sdlc-v1

Files (3)

• SKILL.md
• openai.yaml · agents/
• classification.md · references/

SKILL.md (first lines)

Follow `~/.agents/sdlc/READING.md`; reuse required documents already read in
full, unchanged and retained in context. A skill transition does not reload them.

# Prepare an SDLC v1 project for SDLC v3

`sdlc-init` invokes this writing migration with the configured
`delivery.definition` harness, provider where applicable, and model. Do not
substitute an audit model or a hardcoded model preference.

If `~/.agents/sdlc/MAIN.md` is absent or unreadable, report that exact path;
never search for another copy.

Read `~/.agents/sdlc/MAIN.md`, `~/.agents/sdlc/ISSUES.md`,
`~/.agents/sdlc/TESTING.md`, `~/.agents/sdlc/DOCUMENTATION.md`, and
`~/.agents/sdlc/GIT.md` in full. Consult project documentation only as needed
for the targeted staleness pass.

## Outcome and boundary

This is a fast archival and classification pass, not a historical review. It
produces:

1. an accurate, complete, and current `docs/ACs.org`, produced by losslessly
   converting the normally pre-existing `docs/ACs.md` before reconciliation;
2. a lossless ticket snapshot under `docs/archive/migrated-tickets/`;
3. a concise `docs/ticket-migration.org` migration index;
4. targeted corrections to stale project documentation;
5. the unchanged move of the single file matching
   `docs/implementation?plan.md` to `docs/archive/` with the same basename,
   when the source exists; and
6. closure of every legacy issue after the archive is committed.

Do not invoke `sdlc-init`, create SDLC v3 artefacts, change tests or
implementation, or migrate undelivered scope into `docs/ACs.org`. Do not inspect
old code, search Git history ticket by ticket, re-litigate design, reproduce
historical verification, or add migration comments to tickets.

Explicit invocation authorizes the defined final closure batch. It does not
authorize ticket-body, label, milestone, test-table, pull-request, or unrelated
GitHub mutations.

## Archive every issue once

Use the authenticated GitHub interface for the current repository. Retrieve
every actual issue, open and closed, with all comments and the timeline events
needed to identify linked code commits; exclude pull requests and do not iterate
an assumed numeric range. Download into an operating-system temporary staging
directory, verify complete issue, comment, and timeline pagination, then promote
the complete snapshot to `docs/archive/migrated-tickets/`.

Write one `<issue-number>.md` file per issue containing:

- issue number and descriptor, original URL, snapshot state and reason, labels,
  milestone, author, and creation and closure dates;
- the complete original issue body; and
- every comment in chronological order, with author and timestamp; and
- every code-commit reference recorded in the body, comments, or ticket
  timeline.

Write `manifest.json` in that directory with repository identity, snapshot
time, issue count, open and closed counts, pagination result, and filenames.
Preserve archived source text exactly; do not sanitize it.

The tracked archive is the immutable cache. Read only it for all later ticket
passes and never re-fetch individual issues. A purpose-created baseline issue
is the sole exception: create and archive it exactly once, then add it to the
manifest. If staging is incomplete or the destination contains conflicting
material, stop before closure.

## Start the durable migration index

Immediately after verifying and promoting the archive, create
`docs/ticket-migration.org` from
`~/.agents/sdlc/templates/migration/ticket-migration.org`. Read that template in
full and follow its embedded structure, syntax, and validation instructions. If
an interrupted migration already has an index, preserve its recorded state and
reconcile its structure rather than overwriting it.

Update the document after each completed evidence phase and immediately after
classifying each ticket. Incremental writes are required; per-ticket commits are
not. Give every ID a descriptor and link ticket titles to the local archived
files. Keep complete source text in the archive rather than duplicating it here.

## Normalize the legacy AC ledger before reconciliation

Use `VALID` for an applicable legacy AC, never `HOLD` or `HOLDING`. Keep test
results and heuristic qualifications separate; validity is not a test pass.
Those old generated labels are compatibility inputs, not blocked-work states.

Read `~/.agents/sdlc/templates/migration/ACs.org` in full. Before indexing live
RTs or appending migrated ACs, convert the pre-existing `docs/ACs.md` into
`docs/ACs.org` using that canonical structure. Use `git mv` so the tracked
history remains visible and no conflicting Markdown ledger remains.

The conversion is structural, not editorial. Inventory and reconcile every AC
identifier, descriptor, requirement, source, shipped or migration version,
status, test relationship, test status, evidence note, supersession link,
footnote, glossary entry, and explanatory note. Normalize Markdown links,
tables, emphasis, code spans, and footnotes into native Org without summarizing,
silently correcting, reinterpreting, merging, splitting, renumbering, or dropping
information. Counts are supporting checks only; perform a field-by-field
source-to-target reconciliation before continuing.

Remove the AC template's instructional comments and placeholders from the
project ledger. Keep `docs/ACs.org` valid Org throughout the remaining migration
and validate it with Pandoc's Org reader after conversion and before every
repository commit that changes it.

After writing or changing the ledger, cross-check its outline against the
canonical example in `~/.agents/sdlc/templates/migration/ACs.org`. Every AC MUST
be a level-three heading containing both its identifier and a useful descriptor,
for example `*** AC29.1 - Reject an invalid host definition`. An identifier-only
AC heading fails this structural check. Preserve any additional source detail
under the canonical nested fields.

If `docs/ACs.org` already exists and `docs/ACs.md` does not, validate it against
the template and resume. If both exist, stop and report the conflict rather than
choosing or merging a ledger. If neither exists, initialize an empty
`docs/ACs.org` from the canonical template; do not invent legacy entries. After

From tigger-developer/sdlc, Apache-2.0.

More from tigger-developer/sdlc