Project advisor

Skill bks-lab/open-bridge/skills/project-advisor

Your AI coding agent starts every session knowing your repos, your clients, and how you work — a plain git repo of markdown + YAML it reads at session start, independent of model or frontend. Context compounds instead of restarting. MIT.

Install

npx -y skills add bks-lab/open-bridge --skill project-advisor

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Governance and execution for GitHub and ADO projects — reads per-project configs from workflow/projects/*.yaml for field values, governance rules, and state mappings. Handles issue creation, field updates, board health validation. Trigger: "create issue", "board health", "project setup", "check governance", "update field", "convert drafts".

SKILL.md

5.3 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

Project Advisor

Governance layer for project management. Reads per-project configuration from workflow/projects/*.yaml to know field values, governance rules, and state mappings. Actual execution (creating issues, updating fields) goes through the github-projects-manager skill.

This skill is cross-cutting — applies to every repo that uses GitHub Projects or Azure DevOps Boards, not just The Bridge.

Project Registry

Configuration lives in workflow/projects/*.yaml. Each file defines one project:

Field values (status, priority, type, size, stage, etc.)
Governance rules (K/W/B levels, per-rule overrides)
State mappings (project status → normalized state for trackers)
Review comment templates

projects/
├── _schema.yaml              # Schema documentation
├── _template.yaml            # Blank template for new projects
├── examples/                 # Neutralized examples (CORE layer)
│   ├── operational.yaml      # Type A: management, coordination
│   ├── technical.yaml        # Type B: software development
│   ├── minimal.yaml          # Type C: workshops, experiments
│   └── ado-project.yaml      # Azure DevOps integration
└── {slug}.yaml               # Actual project configs (USER layer)

When creating issues or updating fields: always read the matching workflow/projects/{slug}.yaml first. Use the field values defined there — never hardcode emojis, status names, or priority values.

When This Skill Activates

User asks about project setup or structure
User wants to validate board health or check governance
Crew-advisor detects untracked work that should be an issue
After issue creation (verify governance rules were followed)

Decision Tree

User intent?
├─ "Set up a GitHub project"         → references/setup.md
├─ "Create issue" / "Track this"     → Issue Governance (below) + references/execution.md
├─ "Show board" / "What's active?"   → Board Overview (below)
├─ "Check board health"              → references/governance.md (R1-R7) + execution.md (jq queries)
├─ "Update issue status/fields"      → references/execution.md (CLI + GraphQL patterns)
├─ "Convert drafts to issues"        → references/execution.md (Draft-to-Issue section)
├─ "Add a new project"               → Create workflow/projects/{slug}.yaml from _template
└─ General project question           → Answer from governance.md + project config

Issue Governance (guided flow)

When creating an issue (execution patterns in references/execution.md):

Load project config
- Match context to workflow/projects/*.yaml (by project number or name)
- Read fields: for valid values, governance: for rules
- If no config exists: offer to create one from _template.yaml
Determine project type from config project.type:
- operational → has assignment + dependency fields
- technical → has stage + size fields
- custom → minimal fields, check what's available

Propose issue (use field values from config):

Issue proposal:
  Title: {derived from conversation}
  Repo: {from config project.issue_repo}
  Project: #{number} {name}
  Fields: (per config)
    Status: {config fields.status.default}
    Priority: {suggested from config values}
    Type: {suggested from config values}

[y] Create  [e] Edit  [n] Cancel

Create via github-projects-manager skill
Verify — confirm issue is on the board after creation

Board Overview

Query active items (exclude done_states from config), show grouped by status with assignee and priority.

Field Update Rules

Read governance.rules from project config. At minimum:

K-level (Critical — from config governance.level: strict|standard):

done_requires_review: must go through review_states before done_states
review_needs_comment: mandatory comment using review_comment_template
done_only_by_user: only human can mark done
never_delete: use Declined, never delete

W-level (Workflow):

assignee_on_in_progress: must have assignee when in progress
comment_on_status_change: comment on every transition

See references/governance.md for the full K/W/B rule set with board health validation checks (R1-R7).

Governance Levels

Level	K rules	W rules	B rules
`strict`	Enforced	Enforced	Suggested
`standard`	Enforced	Suggested	Optional
`relaxed`	Enforced	Informational	Informational