一键导入
daily-briefing
Cross-project status report with health assessment, stale work detection, and methodology insights. Use for a quick overview of all managed projects.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Cross-project status report with health assessment, stale work detection, and methodology insights. Use for a quick overview of all managed projects.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Initialize a project for Flight Control. Creates .flightops directory with methodology reference and artifact configuration. Run before using other Flight Control skills on a new project.
Run a behavior test — spawn two live agents (an Executor that performs each step's actions and a Validator that judges each step's expected results), drive them through the spec's step table communicating mid-test so failures surface immediately, then write a run log with evidence. Tests are specs that follow the Witnessed pattern: every action is judged by an independent agent. Verifies system properties through observables (UI state, HTTP responses, shell output, filesystem state) measured via whichever apparatus (MCP, tool) is registered. Invocation: `/behavior-test <slug>` to run a test by slug. Specs are authored inline during flight/leg/mission planning — see `AUTHORING.md` sibling file for the authoring guide. Spec format lives in the target project's `.flightops/ARTIFACTS.md`.
Active orchestrator for multi-agent flight execution. Drives leg design per leg, then batches implementation across all autonomous legs, with a single code review and commit at the end of the flight.
Create technical flight specifications from missions. Use when breaking down a mission into implementable work or planning technical approach.
Between-mission codebase health assessment. Run after `/mission-debrief`, never after an individual flight, to verify the codebase is flight-ready or scaffold a maintenance mission. Per-flight findings instead roll into the next flight or accumulate into an end-of-mission maintenance flight — not into this skill.
Generate detailed implementation guidance for LLM execution. Use when creating atomic implementation steps from a flight.
| name | daily-briefing |
| description | Cross-project status report with health assessment, stale work detection, and methodology insights. Use for a quick overview of all managed projects. |
Generate a comprehensive status report across managed projects with health assessments, staleness detection, and cross-project methodology insights.
projects.md must exist (run /init-mission-control first)Daily briefings are saved to the daily-briefings/ directory in the mission-control repository root, named by date: daily-briefings/YYYY-MM-DD.md. This directory is gitignored — briefings are local-only, ephemeral documents.
If a briefing already exists for today, append a sequence number: YYYY-MM-DD-2.md, YYYY-MM-DD-3.md, etc.
projects.md to get the full list of managed projectsPresent the user with a checkbox list (AskUserQuestion with multiSelect: true) of all registered projects so they can select which ones to include in the briefing.
AskUserQuestion limits each question to 4 options. Split projects across multiple questions in groups of 3, reserving the 4th option as "None from this group" (description: "Skip these projects") so the user can opt out of an entire group without blocking submission. Send all questions in a single AskUserQuestion call.
Format each project option as:
For each selected project, gather data by spawning parallel Explore agents (Task tool, subagent_type: "Explore") — one per project. Each agent should:
Check initialization status
{project-path}/.flightops/ARTIFACTS.md existsRead artifact configuration
{project-path}/.flightops/ARTIFACTS.md for directory structure and naming conventionsDiscover all artifacts
{project-path}/missions/ for mission directoriesRead debriefs
Check git activity
git log --oneline --since="7 days ago" -20 in the project directoryReturn structured findings The agent should return a structured summary including:
For each scanned project, assess health across these dimensions:
Flag artifacts that appear stale or abandoned:
active or planning but no flight activity in 14+ daysin-flight or planning but no leg progress in 7+ daysin-flight or planning but no recent commits in 7+ dayslandedAnalyze all debriefs (flight and mission) across selected projects to extract:
Create the daily briefing file at daily-briefings/YYYY-MM-DD.md. Ensure the daily-briefings/ directory exists first.
Format:
# Daily Briefing — {YYYY-MM-DD}
## Executive Summary
{2-3 sentence overview of portfolio health — how many projects active, key highlights, top concerns}
---
## Project Reports
### {Project Slug}
**Health**: {Active | Stalled | Idle | Fresh} {optional: brief qualifier}
**Recent Activity**: {X commits in last 7 days | No recent commits}
#### Current State
| Level | Active | Completed | Stale | Total |
|-------|--------|-----------|-------|-------|
| Missions | {n} | {n} | {n} | {n} |
| Flights | {n} | {n} | {n} | {n} |
| Legs | {n} | {n} | {n} | {n} |
#### In Progress
- **Mission**: {title} — {status summary}
- **Flight**: {title} — {status}, {X/Y legs complete}
- {Current/next leg and its status}
#### Staleness Alerts
- {Description of stale artifact and how long it's been inactive}
#### Recommendations
- {Actionable recommendation based on current state and debrief insights}
---
{Repeat for each selected project}
---
## Not Initialized
{List any selected projects that lack `.flightops/` — suggest running `/init-project`}
---
## Cross-Project Insights
### Common Patterns
{Themes observed across multiple project debriefs}
### Methodology Observations
{Feedback about Flight Control itself — what's working, what could improve}
### Recommended Actions
1. {Highest-priority cross-project action}
2. {Second priority}
3. {Third priority}
After writing the briefing file, present a concise verbal summary to the user:
Keep the verbal summary short — the detailed report is in the file.
This skill only reads project artifacts and git history. It never modifies any project files, artifacts, or source code.
Spawn project scanning agents in parallel for efficiency. Don't scan projects sequentially.
.flightops/ get noted but don't block the reportReport what you find. Don't sugarcoat stale projects or inflate activity. The briefing is for situational awareness — accuracy matters more than optimism.
The written briefing is the detailed artifact. The verbal summary should be 5-10 lines max — just the highlights and the file path.