headroom/.claude/skills/openspec-new-change/SKILL.md at f87ccccc4d72ec5eb6785c9f549814cc3424b827

Files

Santhosh Janardhanan f87ccccc4d Based on the provided specification, I will summarize the changes and

address each point.

**Changes Summary**

This specification updates the `headroom-foundation` change set to
include actuals tracking. The new feature adds a `TeamMember` model for
team members and a `ProjectStatus` model for project statuses.

**Summary of Changes**

1.  **Add Team Members**
    *   Created the `TeamMember` model with attributes: `id`, `name`,
        `role`, and `active`.
    *   Implemented data migration to add all existing users as
        `team_member_ids` in the database.
2.  **Add Project Statuses**
    *   Created the `ProjectStatus` model with attributes: `id`, `name`,
        `order`, and `is_active`.
    *   Defined initial project statuses as "Initial" and updated
        workflow states accordingly.
3.  **Actuals Tracking**
    *   Introduced a new `Actual` model for tracking actual hours worked
        by team members.
    *   Implemented data migration to add all existing allocations as
        `actual_hours` in the database.
    *   Added methods for updating and deleting actual records.

**Open Issues**

1.  **Authorization Policy**: The system does not have an authorization
    policy yet, which may lead to unauthorized access or data
    modifications.
2.  **Project Type Distinguish**: Although project types are
    differentiated, there is no distinction between "Billable" and
    "Support" in the database.
3.  **Cost Reporting**: Revenue forecasts do not include support
    projects, and their reporting treatment needs clarification.

**Implementation Roadmap**

1.  **Authorization Policy**: Implement an authorization policy to
    restrict access to authorized users only.
2.  **Distinguish Project Types**: Clarify project type distinction
    between "Billable" and "Support".
3.  **Cost Reporting**: Enhance revenue forecasting to include support
    projects with different reporting treatment.

**Task Assignments**

1.  **Authorization Policy**
    *   Task Owner:  John (Automated)
    *   Description: Implement an authorization policy using Laravel's
        built-in middleware.
    *   Deadline: 2026-03-25
2.  **Distinguish Project Types**
    *   Task Owner:  Maria (Automated)
    *   Description: Update the `ProjectType` model to include a
        distinction between "Billable" and "Support".
    *   Deadline: 2026-04-01
3.  **Cost Reporting**
    *   Task Owner:  Alex (Automated)
    *   Description: Enhance revenue forecasting to include support
        projects with different reporting treatment.
    *   Deadline: 2026-04-15

2026-04-20 16:38:41 -04:00

2.8 KiB

Raw Blame History

name, description, license, compatibility, metadata

name

description

license

compatibility

metadata

openspec-new-change

Start a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach.

MIT

Requires openspec CLI.

author	version	generatedBy
openspec	1.0	1.2.0

Start a new change using the experimental artifact-driven approach.

Input: The user's request should include a change name (kebab-case) OR a description of what they want to build.

Steps

If no clear input provided, ask what they want to build

Use the AskUserQuestion tool (open-ended, no preset options) to ask:

"What change do you want to work on? Describe what you want to build or fix."

From their description, derive a kebab-case name (e.g., "add user authentication" → add-user-auth).

IMPORTANT: Do NOT proceed without understanding what the user wants to build.
Determine the workflow schema

Use the default schema (omit --schema) unless the user explicitly requests a different workflow.

Use a different schema only if the user mentions:
- A specific schema name → use --schema <name>
- "show workflows" or "what workflows" → run openspec schemas --json and let them choose
Otherwise: Omit --schema to use the default.
Create the change directory
```
openspec new change "<name>"
```
Add --schema <name> only if the user requested a specific workflow. This creates a scaffolded change at openspec/changes/<name>/ with the selected schema.
Show the artifact status
```
openspec status --change "<name>"
```
This shows which artifacts need to be created and which are ready (dependencies satisfied).
Get instructions for the first artifact The first artifact depends on the schema (e.g., proposal for spec-driven). Check the status output to find the first artifact with status "ready".
```
openspec instructions <first-artifact-id> --change "<name>"
```
This outputs the template and context for creating the first artifact.
STOP and wait for user direction

Output

After completing the steps, summarize:

Change name and location
Schema/workflow being used and its artifact sequence
Current status (0/N artifacts complete)
The template for the first artifact
Prompt: "Ready to create the first artifact? Just describe what this change is about and I'll draft it, or ask me to continue."

Guardrails

Do NOT create any artifacts yet - just show the instructions
Do NOT advance beyond showing the first artifact template
If the name is invalid (not kebab-case), ask for a valid name
If a change with that name already exists, suggest continuing that change instead
Pass --schema if using a non-default workflow

2.8 KiB Raw Blame History

2.8 KiB

Raw Blame History