sdlc-start

---
name: sdlc-start
description: "Use only as part of the Agentic SDLC workflow; on explicit workspace init or run, initialize, resume, continue, or steer one prompt-bound run by exact ref/file. Prompt capture may refine but never invokes this coordinator."
disable-model-invocation: true
---

# Start SDLC

## Help

For `$sdlc-start --help` or `$sdlc-start -h` (including native Claude forms), return concise help and stop before
any workflow step. State the purpose and invocation policy. Show exact usage
for every public action. Describe each public action, positional
argument, and flag in one concise line, including `-h, --help`; say "No
additional public flags" when there are no others. Use only the documented
public interface. For internal or coordinator-only skills, state that boundary
and that no standalone public workflow action exists. After the selected
`SKILL.md` is loaded, help is report-only: do not call any additional tools,
inspect project state, or modify files, private state, Git, or external systems.
Never expose private helper actions or flags or treat help as workflow
authorization.

## Agent Compatibility

Before workflow reads, load `../global-context-management/references/agent-hosts.md`
for the selected agent home, native identity and required runtime setup.

Use `$sdlc-start` in Codex, `/sdlc-start` in Claude Code, or
`/skills:sdlc-start` in the Claude plugin. Dollar-prefixed skill examples
refer to the same named skill on either host; use the native invocation syntax.
Preserve the declared invocation policy, approvals and workflow ownership.
Use available native tools; an unavailable required capability is a blocker,
never permission to bypass a guard or claim unobserved behavior.

## Purpose

Coordinate the SDLC loop by reading specs, checkpoints, steering input, and
local state, selecting the next feature, refreshing auto-steering when needed,
and choosing exactly one next skill.

## Public Interface

Expose exactly these two actions:

```text
$sdlc-start workspace init [project-folder]
$sdlc-start run <prompt-ref-or-file>
```

- `workspace init` defaults to the exact current folder and may run before Git
  is initialized.
- `run` accepts one exact unique prompt ref, full prompt ID, managed absolute
  path, or managed filename.
- Steering means editing the same prompt and repeating `run`.
- After explicit binding:
  direct prompts may be captured into the canonical prompt.
  Prompt-session intake must never invoke this coordinator.
  It does not invoke either public action.
  The internal merge accepts only a durable project-intent projection, rehashes
  it against the accepted digest, and binds that digest to the operation
  marker. Ephemeral workflow/skill, shell/tool, delivery, agent-control,
  status, conversation, and unrelated wrappers remain outside the prompt;
  commands remain eligible when they define a project contract or example.
  Capture failure never blocks the direct turn, exact duplicates never append,
  and distinct prompt drift never auto-rebases.
- Do not expose bare resume, prompt IDs, run IDs, phase actions, aliases, or a
  separate steering command.

## When To Use

- The user explicitly invokes one of the two public actions.
- A Stop-hook continuation prompt repeats `run` with the bound prompt filename.
- An active run needs the next phase selected after a skill completes.

## When Not To Use

- Do not use to implement code directly.
- Do not use to free-edit requirements or design.
- Do not use to commit, push, create PRs, review PRs, or merge directly.

## Inputs

- `docs/requirements.md`.
- `docs/design.md` when present.
- The selected project root's active `AGENTS.md`, `AGENTS.override.md`, or
  configured fallback instruction file when present.
- Existing local run state when present.
- The bound managed prompt and its latest immutable accepted revision.
- Active `STEERING.md` and `steering/auto-steering.json` when present.
- Optional user-provided live experiment environment information for
  requirements capture.

## Required Reads

- `docs/requirements.md`.
- `docs/design.md`.
- `references/prompt-workspace.md` before prompt initialization, intake,
  binding, steering, or legacy-run decisions.
- `<agent-home>/sdlc-runs/<project-id>/active-run.json` when present.
- Active run state under `<agent-home>/sdlc-runs/<project-id>/<run-id>/`.
- `current-state.json`, `feature-queue.json`, `fingerprints.json`,
  `checkpoints/latest.json`, and the latest checkpoint file.
- `STEERING.md`.
- `steering/auto-steering.json` when present.
- The canonical project-spec observation/receipt and any project-instruction
  advisory already present in private state. Historical lifecycle state is not
  an input.
- Latest feature evidence and failure logs.
- The active `failure-event-v1`, optional `diagnosis-v1`,
  `repair-control-v1`, append-only repair journal, and current repair pointer.
- Active feature execution coordinator and registered worktree state when
  preparation has started.
- `references/state-schema.md` for state fields and transitions.
- `assets/hooks/README.md` when maintaining optional SDLC PreToolUse or Stop
  hooks.

## Writes

- `active-run.json` only when starting or switching the active run.
- Project-level `workspace.json`, `activity.json`, managed prompts, and the
  editor workspace through the private prompt helper.
- Run-level `prompt.json` and immutable `inputs/rNNNN/prompt.md` snapshots
  through the private prompt helper.
- `run.json`, `current-state.json`, `feature-queue.json`, and
  `fingerprints.json`.
- `checkpoints/checkpoint-*.json` and `checkpoints/latest.json`.
- `history/iteration-*.md` for state transitions.
- Local blocker summaries.
- Repair pointers in current state and checkpoints. Structured repair records
  remain owned by the deterministic `sdlc-classify-failure` helper.
- Checkpoint pointers to execution state; Git resource mutation remains owned by
  `sdlc-prepare-execution`, `sdlc-implement-plan`, and `sdlc-commit`.
- Optional canonical project-spec observations. Agentic SDLC never creates or
  edits project instruction files as an automatic workflow phase.

## Process

- Read `references/state-schema.md` before initializing or repairing local state.
- Read `references/prompt-requirements-refinement.md` before requirements
  extraction, clarification, or deciding that a follow-up has no product effect.
- For `workspace init`, invoke private `prompt_workspace.py init`; create or
  verify the exact project workspace, preserve all prompts and history, create
  one starter only when empty, optionally open the CODE/PROMPTS editor
  workspace with a default `Agentic SDLC: New Prompt` task plus history and
  queue tasks, keep generated `00-START-HERE.md` visible but excluded from
  prompt parsing, report metadata-only history, and stop without starting a
  run. New Prompt allocates a fresh ID; do not clone managed prompts. The
  private `new`, `list`, `queue-list`, `queue-cancel`, `queue-next`, and
  `verify` actions are editor/state helpers, not additional public skill commands.
  Private `refinement-ready` is a read-only requirements lock helper for
  context/design admission; `refinement-verify` settles full prompt impact
  after design. Neither is an additional public skill command.
- For `run`, invoke private `prompt_workspace.py intake` before reading or
  changing phase state. Trust only its validated bound run, revision, digest,
  and snapshot; never use the editable prompt directly after intake.
- When the workspace is Git-backed and unmanaged, intake resolves the actual
  `origin` default through its symbolic `HEAD`. A new run on that clean default
  creates and switches to `feature/sdlc-<run-hash>` from the verified remote
  SHA. In a managed `worktree` child, execution instead retains the exact local
  child branch and `HEAD` without fetching or consulting a remote default. A
  recorded run reuses its exact promotion identity; drift blocks instead of
  creating another branch or worktree.
- Route `new` into normal run initialization, `resume` through checkpoint
  reconciliation, active same-prompt `steering` only to
  `sdlc-auto-steering`, and `done` to `ALREADY_COMPLETE`. Intake for a
  different prompt while a run is active durably accepts or updates it in the
  private FIFO queue; creating or saving a prompt never queues it. Do not
  overtake the active run or reorder queued prompts.
- When initializing or resuming, mirror the bound prompt filename, ID, latest
  revision, digest, and snapshot pointer into `run.json`; fail closed if that
  mirror disagrees with `prompt.json`.
- Accept an exact manual prompt rename only when the old source is absent, the
  prompt ID is unique, and normalized intent equals the bound revision. Repair
  the binding and run mirror before continuation. Raw metadata, comment, and
  formatting changes do not create work. Reject rename plus an intent edit,
  duplicate/stale copies, or intent-digest disagreement; rename first, run
  once, then edit and rerun.
- Require `sdlc-auto-steering` to link the accepted prompt ID, revision,
  digest, and snapshot in its ledger, then call private `steering-resolve`
  after recording an `applied`, `blocked`, or `no_effect` disposition. An
  `applied` or `no_effect` transition additionally requires the current
  owner-validated impact receipt and matching derived effect.
- At the beginning of a new run, first apply
  `references/prompt-requirements-refinement.md`. Extract the full Ask and any
  optional headings into normalized product truth, inspect discoverable facts,
  and persist stable clarification IDs privately. Route to
  `sdlc-create-requirements`; block design/planning only for material open or
  reopened questions. Answers may arrive through chat or a later prompt
  revision, and a contradiction reopens the same question ID. Before the first
  adapter publication when either canonical document is absent, invoke
  `maintain-project-specs` to bootstrap the missing draft pair under its
  ownership. Preserve existing document bytes, use evidence-backed stable IDs,
  and keep new design records draft and not-started with substantive decisions
  pending context/design. This bootstrap grants no planning or execution
  authority. Before leaving requirements, invoke private
  `prompt_workspace.py refinement-ready` for the exact workspace and run. It
  checks the latest accepted identity, ready refinement and exact compiled
  requirements without requiring a ready design or publishing impact evidence.
  Then, when
  `docs/requirements.md` is missing or
  lacks a Live Experiment Environment section, encourage the user to provide a
  non-production or disposable environment with safe connection steps, allowed
  actions, reset instructions, and evidence limits. Do not block the workflow
  only because the section is not provided.
- If the user provides live experiment environment details, route that update to
  `sdlc-create-requirements`; `sdlc-start` must not write `docs/requirements.md`
  directly or store raw environment details in local run state.
- Use the project ID returned by the validated workspace or intake result and
  read its `active-run.json` before choosing a run. Never recompute prompt
  workspace identity from repository metadata.
- Acquire or honor the active run lock. It is a private JSON ownership record,
  not an empty file or an OS lock alone: publish the exact workspace project ID,
  selected project root, active run ID, status, owner session hash and timestamp
  using the `active.lock` contract in `references/state-schema.md`. Re-observe
  that hook discovery resolves this same run before dispatching any phase.
  Preserve the record during checkpoint writes. If it appears stale, report
  its owner and timestamp and recover only when no prior writer is active.
- Resume from `checkpoints/latest.json` first. Do not rely on conversation
  memory for current feature, phase, blocker, retry counts, or next skill.
- Reconcile `current-state.json`, the latest checkpoint, feature queue,
  fingerprints, and evidence. If they disagree, prefer the newest complete
  checkpoint that matches existing evidence, then repair `current-state.json`.
- Initialize local run state only when no active run or checkpoint exists.
- If requirements are missing, route to `sdlc-create-requirements`.
- If design is missing or stale and required context is missing, route only to
  `sdlc-gather-context`.
- If design is missing or stale and required context is present, route only to
  `sdlc-create-design`.
- Before design exits and before planning, require
  `scripts/validate_project_specs.py` to validate the exact canonical v2 pair.
  Structural or traceability defects route to the owning requirements/design
  adapter before spec-dependent planning. The resulting receipt describes
  project truth but never authorizes auto-steering, execution, cleanup,
  finalization, or Stop.
- After design is ready, require the design adapter's initial canonical-pair
  admission when files are new: only the selected pair may be dirty, guarded
  repo-root staging makes them tracked, and HEAD remains unchanged. Do not
  advance untracked specs or move the preparation phase's commit earlier.
- After design is ready and before planning, write the complete private impact claim
  and invoke private `prompt_workspace.py refinement-verify`. Require the shared
  owner to bind the latest accepted identity and every extracted statement
  occurrence to the exact current canonical specs and publish the immutable impact receipt.
  Publication is per-run locked, compare-checks the ledger, and preserves then
  skips conflicting crash orphans. An existing execution without a basis receipt
  must use a distinct safe replan for material impact; never relabel unchanged
  plan bytes as current evidence. Requirements readiness alone never unlocks
  planning, steering resolution, execution, integration, or promotion.
- Read every already-effective `AGENTS.md` in the selected instruction chain.
  Do not create, edit, retire, or reload project instructions automatically.
  A user-invoked project-instruction workflow remains separately responsible
  for its own mutation safety and cannot become an SDLC prerequisite.
- Build or refresh the feature queue from `docs/design.md`.
- Check `STEERING.md` and `steering/auto-steering.json` before every
  iteration.
- If there are new or unresolved steering entries, stale steering fingerprints,
  conflicting reminders, or changed requirements, design, context, plan, or
  evidence reminders, route to `sdlc-auto-steering` before selecting the next
  implementation phase.
- Honor `sdlc-auto-steering` dispositions: route `requirements-change` to
  `sdlc-create-requirements`, `design-change` to `sdlc-create-design`,
  `docs-update` to `sdlc-update-documents`, and `needs-human` to a blocked
  human-input state. A `project-agent-instructions-change` disposition is
  advisory unless the current user explicitly requested the separate mutation
  workflow. Only in that explicit case route to `project-agent-instructions`;
  otherwise record the recommendation and continue under already-effective
  instructions.
- Select the highest-priority incomplete feature whose dependencies are complete.
- Keep exactly one feature execution active. After `plan_locked`, route to
  `sdlc-prepare-execution`; after `execution_prepared`, route to `sdlc-tdd` in
  the recorded integration cwd. From TDD through alignment, require phases to
  use that integration checkout and bind evidence to its recorded HEAD.
- During implementation, route repeatedly to `sdlc-implement-plan` until every
  dependency wave is integrated, combined evidence passes, and worker cleanup
  completes. Task agents may run concurrently only inside the current wave.
  Their assignments inherit the accepted root-intent digest and exact spec
  receipt. Workers do not reclassify intent or edit specs; typed `spec_gaps`
  return to the root coordinator for adapter reconciliation and replanning.
- On every gate failure, require an immutable normalized failure event and
  route to `sdlc-classify-failure`. Preserve the failed criterion, exact
  integration commit, environment identity, reproduction oracle, evidence
  digests, and requirements/design/plan fingerprints.
- Let proven mechanical causes bypass diagnosis. Route an ambiguous,
  persistent, intermittent, or cross-boundary failure to `troubleshoot`
  exactly as a conditional diagnostic branch. Persist its diagnosis pointer
  and return every diagnosis to `sdlc-classify-failure`; troubleshooting never
  chooses or executes the repair phase directly.
- Treat `repair-control-v1` as authoritative for blocker identity, route
  history, invalidations, active time, and repair dispatch budgets. Freeze new
  worker dispatch while classifying, diagnosing, or replanning. Stop on missing
  evidence, unresolved competing hypotheses, policy/human decisions, semantic
  routing cycles, or budget exhaustion.
- A successful repair with invalidations enters the repair-control
  revalidation cursor. Route only to its exact next gate, bind each completion
  to digest-verified evidence and current fingerprints, use the live
  integration HEAD before commit, and bind final commit evidence to completed
  promotion plus a clean promoted checkout on the recorded base branch after
  verified integration cleanup. Do not permit UAT, PR, or publication until
  the cursor is complete.
- For a proven implementation defect, use the active task's existing attempt
  contract only while that task is active. After waves complete, require an
  immutable corrective plan vN+1 and private `replan-future`, preserving full
  completed task definitions/digests and resource-owning waves while appending
  correction tasks and waves.
- Never reopen sealed, promoted, or completed execution. A post-promotion
  failure begins a corrective run from the exact promoted commit.
- Admit failure-driven redesign only after the classifier validates positive
  system-contract proof and the required approval mode. Missing or
  inconclusive implementation evidence is not a design defect.
- Route to `sdlc-commit` only after downstream evidence passes. That phase owns
  final integration sealing, exact fast-forward promotion to the unchanged
  project branch, and integration-resource cleanup. UAT and PR phases use the
  promoted project checkout.
- Set one `next_recommended_skill` based on the current phase.
- After evaluation passes, route to `sdlc-update-documents` when feature-facing
  docs, changelog, examples, or documentation steering need updates, then use
  the general `align` quality gate before commit readiness.
- After UAT, route back to `sdlc-update-documents` before final handoff when UAT
  or final steering requires run-level documentation updates.
- In a managed outer worktree, invoke the private `release-outer-lease`
  transition only after final alignment, UAT, and documentation evidence are
  recorded, the exact promoted child HEAD is clean, and all Agentic SDLC
  integration and worker resources are absent. Record phase
  `outer-integration-pending`, return the recorded primary path/source branch
  plus the exact `$worktree integrate <generated-name>` command, and stop. Do
  not invoke or auto-continue the explicit-only `worktree` skill; wait for a
  fresh user invocation from that primary checkout. After independently
  observing local integration, invoke private
  `complete-outer-integration` to bind the source merge proof; never push the
  child or open a PR from it.
- In an unmanaged final source checkout, treat the shared PR skills as
  restricted SDLC modes: `create-pr` may publish only the clean exact promoted
  SHA, and `review-pr`
  may record findings/readiness without changing the PR head. Any required
  branch change returns through `sdlc-classify-failure` and this coordinator.
  `sdlc-merge-pr` may merge only after an explicit user request and only while
  the remote PR head still equals that promoted and reviewed SHA.
- Before returning a next skill, write a checkpoint containing current feature,
  phase, status, blocker, retry counts, last successful phase, fingerprints,
  evidence pointers, repair event/diagnosis/control pointers, and next
  recommended skill.
- Update `checkpoints/latest.json`, then `current-state.json`, after the
  checkpoint is written.
- Write a history entry only when state changes. A repeated resume with no
  state change returns the existing checkpoint and does not duplicate history.
- Stop when complete, blocked, retry budget is exceeded, or human input is
  required. On terminal completion, invoke private `queue-next`; activate the
  unchanged FIFO head only after execution resources are released. Queue-head
  drift requires an explicit rerun of that prompt before activation.
- When the current explicit invocation carried a prompt-session binding
  receipt and owns an active objective transition, register the authoritative
  prompt identity/digest through the internal prompt-session objective
  transition. Mark it terminal only after `ALREADY_COMPLETE` or verified
  workflow completion. Do not register a queued prompt as active before its
  authoritative activation. Direct-prompt capture never supplies a run
  transition or terminal workflow fact.

## Idempotency

- Every invocation starts by reading the latest checkpoint and current state.
- Every `run` starts with prompt intake. An unchanged digest reuses the current
  revision; a changed digest creates exactly one adjacent immutable revision.
- An unchanged completed prompt returns `ALREADY_COMPLETE`; editing that prompt
  starts a linked fresh-full-objective run against current product truth
  without changing completed history. Its `r0001` is not steering. Omission
  alone never deletes accepted requirements.
- Repeating the same invocation with unchanged specs, fingerprints, evidence,
  and steering returns the same current feature and `next_recommended_skill`.
- Repeating with unchanged auto-steering state must not re-route to
  `sdlc-auto-steering` or duplicate steering history.
- On the separately invoked project-instruction route, repeating a verified
  unchanged decision reuses that route's private state and must not rewrite the
  project file. Ordinary SDLC runs do not create or apply that decision.
- Completed features with unchanged fingerprints are skipped.
- Changed requirements or design invalidate only affected features and
  supersede stale plans; they also invalidate the project-instruction decision
  before planning resumes. Locked plan files are never edited in place.
- If execution is already prepared, route requirement/design/plan changes
  through a new locked plan version and private `replan-future`. Replace only
  resource-free planned waves; do not reset or rewrite active/completed
  assignments, commits, worktrees, or evidence.
- History entries, checkpoints, and blocker summaries are append-only except
  for `checkpoints/latest.json` and `current-state.json` pointers.
- Partial writes are repaired by selecting the newest complete checkpoint and
  regenerating derived pointers.

## Failure Handling

- If state is corrupt, reconstruct from the newest complete checkpoint, specs,
  commits, and evidence when possible.
- If an unfinished active run has no managed prompt binding, stop with
  `WORKFLOW_UPGRADE_REQUIRED`. Completed unbound history remains readable; do
  not adopt or migrate it.
- If plan lock conflicts exist, stop and report.
- If any execution coordinator schema v1 through v6 record exists, stop with
  `WORKFLOW_UPGRADE_REQUIRED`, including for completed records. If registered Git identity, plan digest, or
  exact HEAD drifts, stop with the execution-plane failure code rather than
  routing around the coordinator.
- If a feature loops repeatedly, classify the blocker and stop after retry budget.
- If a first direct repair fails with the same blocker, require
  `troubleshoot` before another remediation dispatch. Every retry requires
  newly acquired evidence and a distinct falsifiable hypothesis.
- Do not infer design from an unresolved diagnosis. Stop with the precise
  missing evidence or competing hypotheses.
- If no checkpoint can be trusted, stop with `HUMAN_INPUT_REQUIRED` instead of
  guessing the phase.

## Must Not

- Free-edit requirements or design.
- Create, overwrite, or delete project instruction files as an automatic SDLC
  phase.
- Implement code directly.
- Commit, push, create PRs, review PRs, or merge.
- Bypass validation, tests, or evaluation.
- Route directly from `troubleshoot` to implementation or design.
- Reset repair counters without causally independent blocker evidence or a new
  explicit user-authorized tranche.
- Record live environment credentials, private endpoints, customer data, or raw
  logs in run state.
- Persist prompt content containing detected secret material.
- Create a public workflow CLI. Private helpers may perform deterministic
  workspace, prompt metadata, intake, verification, disposition, recovery,
  replanning, dispatch, and lease transitions only.

## Completion Criteria

- Active run state is accurate and backed by a checkpoint.
- The run is bound to one validated managed prompt and immutable revision.
- Current feature and next skill are explicit.
- Active repair state, owner, invalidations, budgets, and stop reason are
  explicit and checkpointed when a failure cycle exists.
- Steering has been consumed, refreshed, or routed to `sdlc-auto-steering`.
- After implementation and focused verification, route canonical design
  reconciliation through the owner adapter to record separate implementation
  and verification evidence. Satisfied requirements require verified delivery.
- Canonical project-spec observation is checkpoint context, not a workflow
  authorization or completion criterion.
- Each state transition writes a checkpoint and history entry.
- Repeated resumes without state changes do not duplicate history.
- The loop can resume after context loss.

## SDLC Invariants

- Treat `docs/requirements.md`, `docs/design.md`, and any
  provenance-owned project-root `AGENTS.md` as committed project truth.
- `maintain-project-specs` is the sole semantic, schema, paired-publication, and
  validation owner of both canonical specs. Requirements and design phase
  skills write only as its Agentic SDLC adapters; spec receipts are project
  truth evidence, not lifecycle authority.
  Explicit project-instruction changes remain outside the automatic workflow.
- Keep run state, plans, evidence, steering, screenshots, and transcripts under `<agent-home>/sdlc-runs/<project-id>/<run-id>/`.
- Keep editable prompts and project-level prompt workspace metadata under the
  matching private `<agent-home>/sdlc-runs/<project-id>/` directory.
- When an active run exists, reload `current-state.json` and the latest
  checkpoint before changing phase or writing evidence.
- Work on one feature at a time unless the user explicitly asks for a different SDLC shape.
- Parallelism is task-local within one feature: one fresh agent, branch, and
  private worktree per safe task, with the coordinator as the only integration
  and cleanup owner.
- Classify every failure before retrying or routing backward.
- Use MCP servers for browser, GitHub, internal docs, Slack, Confluence, Jira, and other external systems when they are available and appropriate.
- Treat hooks as invariant guardrails only; do not make hooks orchestrate the workflow.
- Keep optional SDLC hook source under `assets/hooks/`. Patch that source first,
  validate it with its local tests, then intentionally sync it to `<agent-home>/hooks`
  with `install-skills.sh --agent <codex|claude> --install-all-hooks`, or with
  `install-skills.sh --agent <codex|claude> --install-hooks sdlc-start/assets/hooks` for an SDLC-only
  hook sync. Add `--register-hooks` only when the operator explicitly wants the
  installer to merge the SDLC `PreToolUse` and `Stop` registrations into
  the selected host registration file described in `agent-hosts.md`.

## Learning Loop

When using this skill, capture durable, reusable, public-safe learnings
in the narrowest appropriate surface only when the task contract allows source edits.
For read-only/report-only work, or when a learning is not public-safe,
evidence-backed, in scope, or free of unverified/vendor-specific claims, do not
edit skill sources; report that it was skipped. Do not capture secrets, private
URLs, customer data, raw logs, or one-off local state.

## Output Contract

Return a concise result with:

- Scope handled and current `REQ-*` or `FEAT-*` IDs.
- Files or local state written.
- Evidence created or checked.
- Failure classification and next recommended skill when blocked.
- Confirmation that private SDLC state was kept out of committed project files.

## References

- Read `references/prompt-workspace.md` for prompt workspace, intake, revision,
  steering-linkage, and legacy-run rules.
- Read `references/state-schema.md` when this skill needs that local policy or schema.
- Read `assets/hooks/README.md` when maintaining or installing optional SDLC hooks.

From nebius/nebius-ps-services at b1924de, shown as plain text under its license: Apache-2.0 (permissive). The license text is in LICENSE.

• SKILL.md29 KB · c516af594e7c
• README.md12 KB · 4b9d5d7fca91
• agents/
• openai.yaml596 B · f17ffab30418
• assets/
• hooks.json.template684 B · bad436a35ce3
• hooks/
• README.md7.5 KB · ea469a8f39cd
• lib/
• __init__.py56 B · a8a3fcb674a6
• sdlc_policy.py35 KB · 8c6193361837
• sdlc_state.py22 KB · 5e69ccc3715c
• pre_tool_use_sdlc_policy.py13 KB · ba42bb22e6cc
• stop_lifecycle_arbiter.py6.7 KB · 935587403643
• stop_sdlc_continue.py41 KB · e7318080fd37
• tests/
• test_sdlc_hooks.py87 KB · 49f13fd1e057
• prompt-template.md705 B · 59f5cd0661df
• prompt-workspace-hub.md1.6 KB · 0f9e57db1f24
• evals/
• trigger-prompts.csv876 B · e33384486793
• references/
• prompt-requirements-refinement.md7.3 KB · 2d9dc9c9c48f
• prompt-workspace.md11 KB · d2c2d170d4f4
• state-schema.md26 KB · 05485d605ab4
• scripts/
• prompt_impact.py22 KB · df2463d58b6d
• prompt_workspace.py155 KB · 50deb6711929
• test_prompt_workspace.py69 KB · c638c141a955
• test_sdlc_start_contract.py10 KB · 87b9b6ddec16
• test_validate_project_specs.py7.1 KB · d483d8ff1598
• validate_project_specs.py1.3 KB · 8cfcfac94391

24 files, 567 KB in total. Each file has a sha256 in the pin's manifest; the first 12 characters are shown.