# Mission Brief

> >-

- **Type:** Skill
- **Install:** `agentstack add skill-tikalk-adlc-team-skills-mission-brief`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [tikalk](https://agentstack.voostack.com/s/tikalk)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [tikalk](https://github.com/tikalk)
- **Source:** https://github.com/tikalk/adlc-team-skills/tree/main/skills/mission-brief
- **Website:** https://github.com/tikalk/agentic-sdlc-12-factors

## Install

```sh
agentstack add skill-tikalk-adlc-team-skills-mission-brief
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# mission-brief

## What this skill does

`mission-brief` takes a feature description, structures it into a **Mission
Brief** (goal, constraints, success criteria), generates an ordered **step
list** with prompts, and executes those steps — each step dispatched to a
subagent whose prompt triggers the installed SDD skills. No YAML workflow
files, no per-framework profiles, no profile detection. The step prompts use
canonical SDD terminology (specify, plan, implement, converge) that works with
**any** SDD skill set — model-invoked skills auto-trigger, command-based
frameworks match by filename, and if neither exists the subagent executes
directly.

## When to use

- "Build this feature end to end": you give a description, mission-brief
  composes the pipeline and runs specify → plan → implement ↔ converge.
- You want a converge loop with a circuit breaker and an audit trail.
- You want to resume an interrupted mission across sessions
  (`mission-brief --resume`).
- You want to run unattended across sessions (`mission-brief --async`).

## When NOT to use

- A single small edit — just do it; a mission is overhead.
- You already have a spec and tasks and only want to implement one task —
  invoke the implement skill directly.

## Mission Brief template

Before generating steps, the description is structured into:

```markdown
## Mission Brief

**Goal**: 
**Constraints**: 
**Non-Goals**: 
**Success Criteria**:
- 
- 
- 
```

The brief serves two purposes:
1. **Forces explicit done-criteria upfront** — feeds the converge step's
   independence check (the checker verifies against these criteria).
2. **Carries mission context** into every step's delegation prompt so each
   subagent has full context without re-reading prior steps.

## Inputs

```text
$ARGUMENTS
```

The text in the `$ARGUMENTS` block above **IS** your mission description —
proceed with it immediately. Do not ask the user what they want to build.

Parse flags from the arguments first, then treat the remaining text as
`spec_description`:

- `--async` / `--sync` — execution mode flag (overrides config default).
- `--resume` — explicit resume from state.
- Everything else — the mission description (`spec_description`).

If no description and not `--resume`: derive a best-effort description from the
feature name (git branch, or the last state's feature). If `--resume` and no
state: report "No interrupted mission found" and stop.

**Feature name derivation**: slugify the description to lowercase-hyphenated,
drop stop words (a, an, the, new, to, with, for, add, fix, update). Example:
"add a new react dashboard with telemetry" → `react-dashboard-telemetry`.
If `.adlc/workflow/runs/` already contains a dir with that name, append `-2`,
`-3`, etc.

## Flow

> **All paths are relative to the current working directory** (the project
> root where the agent operates). Do not look in subdirectories for config or
> state unless explicitly stated.

### Phase 0 — Configuration

1. `mkdir -p .adlc/workflow` (and `.adlc/workflow/tmp`, `.adlc/workflow/runs`).
2. If `.adlc/workflow/workflow-config.yml` does not exist, copy it from the
   skill's `config-template.yml` (located alongside this SKILL.md).
3. Read `.adlc/workflow/workflow-config.yml`. Defaults if fields are absent:

```yaml
workflow:
  execution: sync            # sync | async
  supervision: gated         # gated | hybrid | autonomous
  max_iterations: 5
  max_spec_corrections: 2
  circuit_breaker: 3
  quality_threshold: null    # optional 0-100, blocks DONE below threshold
  # models: { strong: "...", fast: "..." }   # optional
```

Resolve the effective execution mode: `--async`/`--sync` flag > config
`execution` > `sync`. If `--async` and `supervision` is `gated`/`hybrid`: warn
("async forces ungated; running autonomous") and treat as `autonomous` for
this run.

### Phase 1 — Resume check (`--resume` only)

> `` = `.adlc/workflow/runs//` (defined in Phase 4, but
> referenced here for the completed-mission check).

If `--resume` was passed:

1. Read `.adlc/workflow/.mission-state.json`.
2. If `/mission-log.json` exists → report "Mission already
   completed for feature X. Audit trail: …" → stop.
3. If state exists with non-empty `completed_steps` → resume: load the step
   list from `state.steps`, skip to Phase 5 (Execute) at the first incomplete
   step.
4. If no state → report "No interrupted mission found. Run
   `mission-brief \"\"` to start one." → stop.

If `--resume` was NOT passed and a state file with non-empty `completed_steps`
exists: **ask** — "An interrupted mission for feature X exists (N/M steps
done). Run `mission-brief --resume` to continue, or confirm to start fresh
(this discards the state)." Do not silently clobber.

### Phase 2 — Mission Brief

Structure `spec_description` into the Mission Brief template:

1. **Goal**: extract the core objective in one sentence.
2. **Constraints**: infer tech stack, limitations, and requirements from the
   description and the project context (check `package.json`, `go.mod`,
   language files, existing specs). If unclear, leave a placeholder and mark
   it for the user to fill.
3. **Non-Goals**: infer 1–2 reasonable boundaries or features that should be
   explicitly excluded to keep implementation focused and simple. If none can
   be inferred, mark as "None".
4. **Success Criteria**: derive 2-5 measurable outcomes. If the description is
   vague, generate reasonable defaults based on the feature type and mark them
   as "suggested — edit if needed".

**Present the brief** to the user:
- sync + gated/hybrid → show the brief and ask for confirmation or edits
  before proceeding.
- sync + autonomous → if Success Criteria are "TBD" or empty, **STOP**: 
  "Autonomous mode requires checkable done-criteria." Otherwise proceed
  without confirmation.
- `--async` → proceed without confirmation (autonomous, ungated).

Store the brief in `.mission-state.json.brief`.

### Phase 3 — Route classification & optional phases

Classify into `spec` / `change` / `quick`:

| Route | When | Steps |
|---|---|---|
| `spec` | New feature, greenfield, "add/create/build" | brainstorm? → specify → clarify? → plan → tasks → analyze? → implement↺converge → trace? |
| `change` | Modification, brownfield, "fix/update/refactor" | specify → implement↺converge |
| `quick` | Small task, trivial, "just/quick/simple" | implement only (full brief as input) |

For `spec` route only, assess optional-phase **candidates** (hands-off,
recorded in state; the user approves each at a runtime gate if supervision is
gated/hybrid):

| Phase | Candidate when |
|---|---|
| `brainstorm` | prompt is architectural/ambiguous ("design", "approach", "compare", "how should we", multiple viable solutions) |
| `clarify` | success criteria are vague / constraints missing |
| `analyze` | route is `spec` (symmetric) |
| `trace` | prompt mentions persistence, audit, traceability, compliance |

### Phase 4 — Command discovery & generate step list

#### 4a. Command/skills discovery

Read `references/agent-integrations.md` (alongside this SKILL.md). For each
agent directory listed in the table, check if it exists in the project root.
Record discovered directories in state:

```json
"discovered": {
  "skills_dirs": [".claude/skills"],
  "commands_dirs": [{"dir": ".opencode/commands", "ext": ".md"}]
}
```

This discovery is done once at generation time and reused on `--resume`. See
the reference file for the full algorithm.

#### 4a.1 Local skills inventory (universal skill routing)

After discovering skills directories (4a), build an inventory of every
installed skill across all `skills_dirs`. For each `//`
subdirectory that contains a `SKILL.md`:

1. Read the `SKILL.md` frontmatter (YAML between `---` fences).
2. Extract `name` and `description` (fall back to the directory name if
   frontmatter is missing or unparseable).
3. Record an entry in `discovered.local_skills`:

```json
"discovered": {
  "skills_dirs": [".claude/skills"],
  "commands_dirs": [{"dir": ".opencode/commands", "ext": ".md"}],
  "local_skills": [
    {"name": "tdd", "path": ".claude/skills/tdd", "description": "Test-driven development with red-green-refactor..."},
    {"name": "grill-me", "path": ".claude/skills/grill-me", "description": "Get relentlessly interviewed about a plan..."},
    {"name": "code-review", "path": ".claude/skills/code-review", "description": "Two-axis review of the diff..."}
  ]
}
```

This inventory is **vendor-agnostic** — it captures skills from any source
(mattpocock/skills, addy osmani/agent-skills, superpowers, custom team
skills, or any Agent-Skills-standard repository). The inventory is passed
to every subagent at dispatch time (Phase 5) so the LLM decides which
skill fits the current step — no hard-coded phase-to-skill mapping tables.

#### 4b. Generate the step list

Generate an ordered list of steps based on the route and optional-phase
candidates. Each step is a structured object stored in `state.steps`:

```json
{
  "id": "specify",
  "phase": "specify",
  "tier": "strong",
  "prompt": "Write a feature specification for the goal below. ...",
  "status": "pending"
}
```

The step list is the **reviewable artifact** — present it to the user in
gated/hybrid mode before execution:

```
## Mission Steps

1. [specify]  (strong) Write a feature specification for: react dashboard with telemetry
2. [plan]     (strong) Break down the specification into an implementation plan
3. [tasks]    (fast)   Generate the detailed task list from the plan
4. [implement](strong) Implement the next pending task from the plan
5. [converge] (fast)   Review the implementation against the spec and success criteria
   ↺ loop 4–5 until converged (max 5 iterations, circuit breaker 3)
```

For `quick` route: single `implement` step with the full brief as input.

For `change` route: `specify` + `implement↺converge` loop (no optional phases).

For `spec` route: full pipeline with optional phases inserted as gated
candidates.

#### Step prompt construction

Each step's `prompt` is built from three parts:

**1. Phase instruction** — canonical SDD terminology per phase:

| Phase | Tier | Instruction |
|---|---|---|
| brainstorm | strong | "Explore approaches and tradeoffs for the goal below. Consider multiple viable solutions and present a recommended design." |
| specify | strong | "Write a feature specification for the goal below. Include requirements, constraints, and measurable success criteria." |
| clarify | fast | "Review the specification and interview the team to resolve any vague success criteria or missing constraints." |
| plan | strong | "Break down the specification into an implementation plan with ordered, verifiable tasks." |
| tasks | fast | "Generate the detailed task list from the plan — each task must have exact file paths and verification steps." |
| analyze | fast | "Adversarially review the plan before implementation. Challenge every non-trivial decision." |
| implement | strong | "Implement the next pending task from the plan. Follow test-driven practices." |
| converge | fast | "Review the implementation against the specification and success criteria. Verify independently — you are the checker, not the maker." |
| trace | fast | "Document the decisions made during this feature as ADRs or a handoff document." |

**2. Mission Brief context** — the goal, constraints, and success criteria
from Phase 2 are appended to every prompt.

**3. Delegation wrapper** — added by the executor at dispatch time (Phase 5).
The wrapper includes `discovered.local_skills` so the subagent can decide
which installed skill (if any) to invoke for the current step.

### Phase 5 — Execute the step list

Create a `todowrite` list mirroring `state.steps`. Mark steps in
`completed_steps` as completed. Update after every step.

#### Step dispatch

For each step with `status: pending`:

1. Emit:
   ```markdown
   ## Workflow Step: 

   **Phase**:  ()
   ```
2. If the step is a **converge** step (phase is `converge`), prepend the
   independence hint to the delegation prompt:
   > You are grading work that another agent produced. Do NOT assume the
   > implementation is correct — verify against the spec independently. Try
   > to make each requirement fail at the primary source (run the test, check
   > the file, grep for the reference). You are the checker, not the maker.
   >
   > **CRITICAL**: Verify that NO features or implementations listed under
   > **Non-Goals** have been introduced. If any out-of-scope work was built,
   > report CONTINUE as your outcome signal, and list the non-goals violation
   > in your summary.
3. Delegate to a subagent with this prompt **verbatim**:

   ```markdown
   You are being invoked by the `mission-brief` executor.

   ## Task

   

   ## Mission Brief

   **Goal**: 
   **Constraints**: 
   **Non-Goals**: 
   **Success Criteria**: 

   ## Available Skills in This Workspace

   

   The list above shows skills installed in this workspace from any source
   (ADLC team skills, mattpocock/skills, addy osmani/agent-skills,
   superpowers, or custom). Review each skill's name and description.
   If one matches the goal of your current task, **invoke it** (via the
   skill tool or by reading its SKILL.md inline) and use it to execute
   this step. If multiple skills could apply, pick the best fit. If none
   apply, proceed with direct execution.

   ## How to execute

   Try these in order:

   1. **Skill match**: If an installed skill's description matches this task,
      invoke it (via skill tool or by reading its SKILL.md inline).

   2. **Command match**: If a command file for this phase exists, read and
      execute it. 
      Look for a file whose name matches the phase (e.g., `*specify*`,
      `*implement*`, `*converge*`).

   3. **Direct execution**: If neither exists, execute the task directly using
      your available tools.

   **Confidence Self-Estimation**:
   Evaluate your confidence (HIGH/MEDIUM/LOW) in this implementation or task. If
   you are missing critical context, have low confidence, or find the requirements
   ambiguous, report `Confidence score: LOW` (or `MEDIUM`) and list the specific
   unresolved details in your return summary.

   If you found a skill or command, note its name in your summary.

   Do NOT follow handoffs to other skills or commands — return your results to
   the executor when you finish.

   Return:
   1. A 1-2 sentence summary (mention which skill/command you used, if any).
   2. Files changed (if any).
   3. Test results (if any).
   4. Outcome signal: DONE | CONTINUE | SPEC_CORRECTION_NEEDED.
      - DONE: work is complete and verified.
      - CONTINUE: more work is needed (tasks remain, review found issues).
      - SPEC_CORRECTION_NEEDED: verification found spec-level issues that
        require re-running specify. Include a `spec_corrections` field with
        the specific issues.
   5. (optional) Quality score: "X/Y (Z%)" — if a verification skill ran
      quality gates, report the score.
   6. (optional) Gate summary: "N passed, M failed" — if quality gates were
      checked, list which passed and which failed.
   7. (optional) Confidence score: HIGH | MEDIUM | LOW. Self-estimated confidence in the correctness of your work.
   8. (optional) Unresolved details: .
   ```

   `` is replaced with a formatted list built from
   `discovered.local_skills`. Each entry shows the skill name, path, and
   description:

   ```markdown
   - **tdd** (`.claude/skills/tdd`) — Test-driven development with red-green-refactor...
   - **grill-me** (`.claude/skills/grill-me`) — Get relentlessly interviewed about a plan...
   - **code-review** (`.claude/skills/code-review`) — Two-axis review of the diff...
   ```

   If `discovered.local_skills` is empty, `` is replaced
   with: `"No custom skills detected in this workspace."`

   `` is replaced with the discovered directories from
   `state.discovered`:
   - If `commands_dirs` is non-empty: "Check these locations:
     `.o

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [tikalk](https://github.com/tikalk)
- **Source:** [tikalk/adlc-team-skills](https://github.com/tikalk/adlc-team-skills)
- **License:** MIT
- **Homepage:** https://github.com/tikalk/agentic-sdlc-12-factors

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-tikalk-adlc-team-skills-mission-brief
- Seller: https://agentstack.voostack.com/s/tikalk
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.
