architect-analyze
Use when validating generated or refined architecture artifacts, before feature development, during architecture review, or…
Use when a mission brief must become a measurable spec — restates every success criterion as a binary outcome and resolves what cannot be measured before any plan exists.
Claude Code
$ npx -y skills add tikalk/adlc-team-skills --skill mission-specify --agent claude-code
Codex
$ npx skills add tikalk/adlc-team-skills --skill mission-specify -a codex -y
Cursor
$ npx skills add tikalk/adlc-team-skills --skill mission-specify -a cursor -y
Gemini CLI
$ npx skills add tikalk/adlc-team-skills --skill mission-specify -a gemini-cli -y
GitHub Copilot
$ npx skills add tikalk/adlc-team-skills --skill mission-specify -a github-copilot -y
OpenCode
$ npx skills add tikalk/adlc-team-skills --skill mission-specify -a opencode -y
Windsurf
$ npx skills add tikalk/adlc-team-skills --skill mission-specify -a windsurf -y
name: mission-specify description: Use when a mission brief must become a measurable spec — restates every success criterion as a binary outcome and resolves what cannot be measured before any plan exists.
**Requires:** the `factory-runbook` skill's shared executor contract at `.agents/skills/factory-runbook/references/executor.md` (installed path); install with `adlc-cli skills add tikalk/adlc-team-skills --skill factory-runbook`.
When `ADLC_RUN_ID` is not set, a person is in this session, and nothing else will answer a gate. The agentic-container runtime that relays gates to Slack exists only in a runner pod.
1. **A paused run is your turn, not the end of the mission.** When `adlc-cli workflow run` or `resume` exits with the run paused at a gate (`run_paused`, `status: paused` in `adlc-cli workflow state show <run_id>`), ask the person the gate's question and options. Then run `adlc-cli workflow resume <run_id> --input <verdict_input>=<answer>` and keep going. Never end your turn on a paused run that nobody was asked about. 2. **Every gate that approves MRs is followed by a step that opens them.** A `gate` whose message promises MRs/PRs is followed by a `publish` step: `run-branch.sh` and `open-mr.sh` for each repository the change touches, writing `mr_url` (`mr_urls` for more than one). Only then comes the write-back step, so the completion comment links real MRs. A gate with nothing after it to act on its answer is a plan defect; fix the plan before you start the run. 3. Before ending your turn, the run is `completed`, `failed` or aborted, or it is paused at a gate the person has been asked about.
`mission-specify` owns the specify phase of the mission SDD family: it turns the mission's `brief.md` into a `spec.md` whose acceptance criteria can each be judged yes or no, and it records the decisions taken to get there. It works under the shared executor contract (`.agents/skills/factory-runbook/references/executor.md`): the `specify` step reads `brief.md` and emits a draft, and the `clarify` step reads `spec.md` and emits a decision, with `reads_from` resolved by the orchestrator. It stops at the spec — planning belongs to `mission-plan`, building to `mission-implement`, verification and convergence to `mission-verify`, and REVIEW and SHIP belong to `factory-review` and `factory-deploy`.
1. Read `brief.md`; treat its goal, constraints, non-goals and success criteria as the input, not as wording to preserve. 2. Restate every success criterion as a binary, measurable outcome — each one answers a yes/no question through a command that exits, an artifact that exists, or a diff that shows the change. 3. Write `spec.md`: outcome, constraints, non-goals, acceptance criteria, and out of scope. Each acceptance criterion stays traceable to the success criterion it restates. 4. Surface any criterion that cannot be measured and any constraint that conflicts with another; do not paper over either in prose. 5. Resolve each surfaced item at the clarify phase — ask the person in a gated run, or in autonomous mode record the decision with its basis. The resulting decision is the `clarify` output. 6. Never select technologies and never plan files; those are later phases.
| Step | phase_type | output_type | reads_from | artifact | |---|---|---|---|---| | `specify` | generate | draft | `brief.md` | `spec.md` | | `clarify` | clarify | decision | `spec.md` | — |
No gate in this phase.
Agent skills that give coding agents your team's context at session start, so they stop working like strangers.
Use when validating generated or refined architecture artifacts, before feature development, during architecture review, or…
Use when architecture work starts or a tech-stack or pattern decision emerges — injects the project ADR index…
Use when ADRs need review, gaps need filling, or ADR status must be approved as Accepted before architecture generation.
Use when accepted ADRs exist and AD.md must be produced or updated as unified architecture documentation.
Use when bootstrapping architecture documentation for a brownfield project by reverse-engineering ADRs from an existing codebase.
Use when you want guided trade-off analysis, multi-option comparison, or structured architectural decision facilitation before…
Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid…
Use when asked to review a plan, challenge a proposal, run a CEO review, poke holes in an approach, think bigger about scope, or…
Converts books and documents (PDF, EPUB, DOCX, HTML, Markdown, plain text, RTF, MOBI/AZW with Calibre) into structured agent…
Set up the owner profile so a personal agent knows who it works for (first-run setup, \"get to know me\"), or distill colleague,…