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: