project-status-report（项目状态报告）

Project Status Report

Overview

Extract project status information from various sources (meetings, messages, emails, documents) and generate structured status reports following standardized markdown templates.

Report files types:

• Single team latest day report of all its projects (will be used to create other compiled files)
• Single team compiled report with all its projects and reports informations in date sections
• Consolidated document grouping multiple team reports
• Consolidated project list

Please, follow the rules/status-report-rules.md to get right guidance and know the main rules of this skill.

Instructions

Always interact with the user, with the same language they are using.

General:

• Use the informations, transcripts and documents given by the user to create the reports
• Learn with notes to understand relations between reports and notes
• If you will update an existing file, read and understand the file before you update with new informations
• Find product/project/initiative in existing notes and update the right block
• Follow template instructions completely
• If unsure where to insert information, ask to user.
• Final output files need to have the yaml filled correctly
• For projects/topics with resolved and done status, move the the right section indicated in templates
• Be prepared to update the notes in the right topic section, when the user give updated informations about one individual topic

Single team report:

• Usually is used to get latest status report of projects until that day.
• Is used for structure informations and status report of one single team and your projects.
• Use templates/template-single-team-status.md
• Group multiple projects under SINGLE team header
• Before create the file, ask user confirmation a list of projects and iniatives the final report will have. User can ask to merge some topics or rename

Compiled Team report (well structured and formatted group of many single team report files):

• Used to group in one file all single team report of one specific team and your projects status reports of multiple days
• To create or update this report, use the single team reports already created before by the user and the informations given by the user
• When the user asks for a latest updated report of all projects of one specific team

- Use the given informations or if the obsidian is used, look for the historical related notes and new related notes to update this report - Look for files that have the same name and content patterns created by this skill or for partterns users already asked in the past

• Output file need to follow the instructions and structure of the template templates/template-single-team-compiled-status.md
• Maintaining structure of the single team report notes, but following the structure and organization of the given template
• Don't change informations or dates when group those notes
• Ask for clarification if individual notes don't exist
• Group multiple projects under SINGLE team header

Multiple Teams Reports (multiple teams, with multiple projects, multiple days):

• Used to group in one file all single report of all teams with many projects status reports of multiple teams
• Output file need to follow the instructions and structure of the template templates/template-multiple-teams-compiled-status.md
• Maintaining structure of single team report notes, but following the structure and organization of the given template
• Don't change informations or dates when group those notes
• Ask for clarification if individual notes don't exist

Giving updated list of projects

• If users wants an updated list of projects in the notes, use the templates/template-projects-list.md file to give the answer.

Critical Structure Rule

CORRECT - Single team header with all projects:

## Team Name

### First Project
#### DD-MM-YYYY
{content}

#### DD-MM-YYYY
{content}

#### DD-MM-YYYY
{content}

### Second Project
#### DD-MM-YYYY
{content}

#### DD-MM-YYYY
{content}

In the project section, dates sections should be organized from newest to oldest.

WRONG - Repeated team headers:

## Team Name
### First Project
...

## Team Name
### Second Project
...

Team name (## Team Name) must appear ONCE with all projects nested under it.

What to Avoid

• Don't update wrong dates or wrong projects
• Don't create extra blocks (Meeting Notes, Learnings, etc.) - follow templates exactly
• Don't assume - ask for clarification when in doubt

When the user have Obsidian

Check if the user use Obsidian. If yes, check if you have access to use skills or available MCP to manipulate notes in Obsidian Vault.

• If user wants to save the files in Obsidian vault, ask for the vault path
• if user want to update or modify an existent note in Obsidian vault, ask for the file path in the vault
• Look in the vault to

Processing Workflow

1. Receive and Analyze

• Detect user's language
• Check for historical context (previous reports)
• Accept input in any format
• Scan for: team names, projects, status, problems, risks, actions, dates

2. Extract Information

For each project:

• Team name (explicit or contextual)
• Project/initiative name
• Summary content
• On track items (positive progress)
• Problems (current blockers)
• Risks & concerns (potential issues)
• Actions (specific next steps)

3. Handle Missing Information

When to ask:

• Critical info missing (team name can't be inferred)
• Contradictory information exists
• Info too vague to populate sections

When NOT to ask:

• Minor details missing but core clear
• Only 1-2 sections sparse (mark empty)
• Team/project names reasonably inferable

4. Generate Output

• Single markdown file with all projects (default)
• Follow template structure
• Use current date following the right format indicated by templates
• Match user's language
• Insert new updates BEFORE old content (reverse chronological)

Critical Rules

NEVER:

❌ Invent dates, deadlines, or timelines ❌ Create action items that weren't stated ❌ Infer problems/risks from neutral statements ❌ Add team members/stakeholders not mentioned ❌ Make up metrics or quantitative data ❌ Fabricate technical details ❌ Assume project status without indication

ALWAYS:

✅ Use only explicitly stated information ✅ Mark sections empty if no relevant info ✅ Preserve original terminology ✅ Use exact dates when mentioned ✅ Quote specific problems/risks as stated ✅ List only explicitly discussed actions ✅ Ask for clarification when needed ✅ Check if updating existing report ✅ Preserve exact structure when updating ✅ Group projects under SINGLE team header ✅ Insert new content BEFORE old (reverse chronological)

Quality Checklist

Before delivering:

• All dates from source or current date following the right format indicated by templates
• No invented action items or problems
• Team/project names accurate or marked uncertain
• All sections present (even if empty)
• Summary factual without speculation
• Format matches template exactly
• Content verifiable from sources
• No hallucinated details
• If updating: exact structure preserved
• Historical context only for terminology, not data invention
• Each team header appears only ONCE
• New content inserted BEFORE old content
• Done/Resolved topics inserted in the right section