@sitar_fiercer4c/skills 0.1.0

package/LICENSE

@@ -0,0 +1,5 @@
+Copyright (c) 2026 thenextepisode-stealth. All rights reserved.
+
+This software is proprietary and confidential. Unauthorized copying,
+distribution, or use of this software, in whole or in part, is prohibited
+without prior written permission from the copyright holder.

package/README.md

@@ -0,0 +1,75 @@
+# skills
+
+Agent skills for Claude Code, distributed as the private npm package `@sitar_fiercer4c/skills`.
+
+Installing the package copies every skill into the `.claude/skills` directory of the project where `npm install` is run.
+
+## Install
+
+You need an npm account that has been added as a collaborator on this private package.
+
+```sh
+npm login                       # or add a read-only token to .npmrc (see below)
+npm install -D @sitar_fiercer4c/skills
+```
+
+The skills land in `./.claude/skills/<skill-name>/`.
+
+For CI, add this to the project's `.npmrc` and set `NPM_TOKEN` to a read-only token:
+
+```
+//registry.npmjs.org/:_authToken=${NPM_TOKEN}
+```
+
+### If install scripts are disabled
+
+With `--ignore-scripts`, pnpm, or bun, the postinstall copy may not run. Copy the skills manually from the project root:
+
+```sh
+npx @sitar_fiercer4c/skills
+```
+
+## Update
+
+```sh
+npm install -D @sitar_fiercer4c/skills@latest
+```
+
+Skills shipped by this package are replaced whenever npm installs a new copy of the package (a fresh `node_modules` or a new version), so local edits to them are overwritten. Other skills in `.claude/skills` are left alone.
+
+npm skips the copy when the installed version is unchanged. To restore the skills in that case, run `npx @sitar_fiercer4c/skills`.
+
+## Uninstall
+
+`npm uninstall` does not remove the copied skills. Delete their folders from `.claude/skills` manually.
+
+## Skills
+
+- architecture-walkthrough
+- autotest-webapp-ui
+- backend-code-review
+- be-brief
+- clarke-list-excel
+- datalab-api
+- find-test-seam
+- frontend-code-review
+- frontend-code-review-2
+- murtaza-breif
+- pdf-to-json
+- record-api-traffic
+- refac-wrt-business-goal
+- system-resource-triage
+- using-git-worktrees
+
+## Development
+
+Each skill lives in `skills/<name>/` with a `SKILL.md`. `evals/` folders are kept in the repo but excluded from the published package.
+
+To publish, load the token from `.env.local` and run:
+
+```sh
+set -a && . ./.env.local && set +a
+npm version patch
+npm publish
+git push --follow-tags
+```

package/bin/install.js

@@ -0,0 +1,45 @@
+#!/usr/bin/env node
+'use strict';
+
+// Copies the bundled skills into <project>/.claude/skills.
+// Runs as a postinstall hook, or manually via `npx @sitar_fiercer4c/skills`.
+
+const fs = require('fs');
+const path = require('path');
+
+const pkgRoot = path.resolve(__dirname, '..');
+const srcDir = path.join(pkgRoot, 'skills');
+const isPostinstall = process.env.npm_lifecycle_event === 'postinstall';
+
+// INIT_CWD is the directory npm was invoked from, i.e. the consumer project.
+const projectRoot = path.resolve(process.env.INIT_CWD || process.cwd());
+
+function main() {
+  // Skip when installing dependencies inside this repo, or for global installs.
+  if (isPostinstall && (projectRoot === pkgRoot || process.env.npm_config_global === 'true')) {
+    return;
+  }
+
+  const destDir = path.join(projectRoot, '.claude', 'skills');
+  fs.mkdirSync(destDir, { recursive: true });
+
+  const installed = [];
+  for (const entry of fs.readdirSync(srcDir, { withFileTypes: true })) {
+    if (!entry.isDirectory()) continue;
+    const dest = path.join(destDir, entry.name);
+    // Replace only skills this package ships; other skills in the folder are untouched.
+    fs.rmSync(dest, { recursive: true, force: true });
+    fs.cpSync(path.join(srcDir, entry.name), dest, { recursive: true });
+    installed.push(entry.name);
+  }
+
+  console.log(`skills: installed ${installed.length} skills into ${destDir}`);
+}
+
+try {
+  main();
+} catch (err) {
+  console.error(`skills: failed to install skills: ${err.message}`);
+  // Never break the consumer's `npm install`; the manual npx command can be rerun.
+  process.exitCode = isPostinstall ? 0 : 1;
+}

package/package.json

@@ -0,0 +1,29 @@
+{
+  "name": "@sitar_fiercer4c/skills",
+  "version": "0.1.0",
+  "description": "Claude Code agent skills, installed into the project's .claude/skills directory",
+  "license": "UNLICENSED",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/thenextepisode-stealth/skills.git"
+  },
+  "bin": {
+    "skills": "bin/install.js"
+  },
+  "scripts": {
+    "postinstall": "node bin/install.js"
+  },
+  "files": [
+    "bin/",
+    "skills/",
+    "!skills/*/evals/**",
+    "!skills/*/datalab_raw/**",
+    "!**/__pycache__/**"
+  ],
+  "engines": {
+    "node": ">=18"
+  },
+  "publishConfig": {
+    "access": "restricted"
+  }
+}

package/skills/architecture-walkthrough/SKILL.md

@@ -0,0 +1,223 @@
+---
+name: architecture-walkthrough
+description: Build up Backend/ARCHITECTURE.md for the murtaza-hotel-project backend one section at a time, tracing real code and walking each section through in chat before writing it. Use this skill whenever the user wants to understand, document, trace, or explain any part of that backend — asks about a workflow (login, Outlook OAuth, inbox, attachment preview, extraction pipeline, quotation editing, Excel/PDF export), asks to fill in or continue ARCHITECTURE.md, asks "how does X work" about that repo, or asks what files run for a given feature. Also use it when adding a new section to that doc, revising one already written, or refreshing sections after the backend code has changed.
+---
+
+# Architecture walkthrough
+
+## What this builds
+
+`/home/dev/workspaces/murtaza-workspaces/murtaza-hotel-project/Backend/ARCHITECTURE.md` — a
+workflow-organised map of that backend, written for someone learning the codebase.
+
+The doc is organised by workflow, not by layer. Each **H2 is a business workflow** (what the user is
+trying to do); each **H3 under it is a technical workflow** that implements part of it. It was
+created deliberately empty — introduction plus headings — and is filled in one H3 at a time.
+
+Read `references/sections.md` for the current section list, the file inventory for each, and the
+findings already verified against source.
+
+## The protocol
+
+This is the part that matters most. The doc is how the reader learns the codebase, so **the chat
+pass is the review and the file is the record.** Writing first inverts that: prose the reader never
+validated accumulates in the doc, and they lose the chance to say "explain that better" or "that
+level is wrong for me" before it sets.
+
+For each section:
+
+1. **Trace the real code.** Open every file in the section's inventory and follow the actual call
+   chain. See "Tracing" below — this is where the section's accuracy is won or lost.
+2. **Draft the section in chat**, complete and in the template format below. Not a summary of what
+   you'll write — the section itself.
+3. **Stop and wait.** Do not touch ARCHITECTURE.md. The user reads it and responds.
+4. **Revise in chat** until they approve. Their questions during this pass are where the section's
+   Notes come from — see "What goes in Notes".
+5. **Then write it** to the doc, as approved.
+
+If the user pre-authorises writing ("just write it", "draft and add 3.5 straight in"), skip the gate
+— but still trace before drafting. The gate is about their review, not about being cautious.
+
+Take one section per pass. Section 3.4, the extraction pipeline, is large enough that it is worth
+splitting across several passes and saying so before starting.
+
+## Updating a section after the code changes
+
+A written section is a claim about code that may have moved on since. When the user says the code
+changed and the doc needs to catch up, do not re-derive the section from scratch and do not trust
+what it currently says.
+
+Work one section at a time, through the same gate as writing a new one:
+
+1. **Read the section as it stands**, then re-trace its inventory files in the current source.
+2. **Work out what actually differs** — citations that no longer land on the code they name, claims
+   about the flow that no longer hold, and code the section never mentioned.
+3. **Draft the revised section in chat**, complete and in the template format, and say plainly what
+   changed and what you are leaving alone.
+4. **Stop and wait**, revise until approved, then write it.
+
+Keep the gate here rather than rewriting straight in. A section that has been through the user's
+review carries their decisions about depth and emphasis, and a silent rewrite discards them where
+the reader has no way to notice. Showing the diff in chat is also what tells them whether the change
+is a line number or a change in how the system works.
+
+If the trace turns up code with no home in the doc — a new service, a step no section covers —
+propose where it belongs rather than filing it silently or leaving it out.
+
+## Tracing
+
+Every claim in a section must come from source you opened. Three things in this repo will mislead
+you if you trust them:
+
+- **Doc comments in the code.** Most comments in `email.controller.js` and `email.service.js` say
+  the routes are `/api/email/...`. They are wrong — `app.js:92` mounts that router at `/api`, so
+  the real path is `/api/inbox`. A whole section was drafted incorrectly from these comments before
+  anyone opened `app.js`.
+- **The repo's other docs.** `README.md`, `QUOTATION.md`, `ATTACHMENT_TO_EXCEL_FLOW.md` and
+  `CODE_REVIEW.md` all predate the 2026-08-30 extraction refactors. They describe Datalab as an
+  optional step after OfficeCLI; it now runs in parallel with bounding-box merging.
+- **A subagent's summary.** Subagents are useful for locating files and listing importers. They read
+  excerpts, so their narrative of a flow is a lead to verify, not a source to quote.
+
+Cite `file.js:LINE` for every function you name, and confirm the line still holds what you say it
+does before writing it down.
+
+## The section template
+
+Read sections 3.1–3.3 in ARCHITECTURE.md before drafting. **They are the format specification** — if
+they and this skill ever disagree on shape or voice, the doc wins, because it reflects the most
+recent round of the user's feedback.
+
+Their Notes blocks are the one thing not to copy the scale of. Those notes accumulated over several
+rounds of the reader asking questions, so a written section holds more of them than any draft of it
+did. Match their voice, not their length.
+
+````markdown
+### 3.N Section name
+
+**What this does for the business workflow:** 15–30 words, plain English, from the operator's point
+of view. What they are trying to accomplish, and what this step contributes.
+
+`METHOD /path` — or, when a section covers more than one endpoint, a sentence naming each.
+
+**Input:** what arrives — auth state, URL params, query flags, body.
+
+**Output:** what goes back, plus side effects (documents written, jobs started).
+
+**Files:** the files whose code actually runs, comma-separated, backticked.
+
+```
+[ASCII diagram]
+```
+
+**Notes** (optional)
+
+Unnumbered paragraphs, one idea each. See "What goes in Notes" — often absent on a first draft.
+````
+
+**Do not add a Steps block by default.** The diagram, plus whatever notes the diagram cannot hold,
+is the finished shape. The diagram already carries the sequence, so prose that walks the same stages
+again is the same information twice and buries the notes that are actually load-bearing.
+
+Add **Steps** only when the reader asks for more — "explain each step a little more", "I can't
+follow the diagram here". Then write one bold imperative title per stage, numbered to match the
+diagram's `(1)…(N)`, two to four sentences each:
+
+```markdown
+**Steps**
+
+**(1) Imperative title.** Two to four sentences expanding that stage of the diagram.
+```
+
+Section 3.3 in the doc carries Steps because the reader asked for them there. Do not read that as
+the default.
+
+## What goes in Notes
+
+Every note costs the reader a detour away from the diagram, so a note has to earn its place, and
+there are only two ways it can.
+
+**One: the fact has no shape in a flow.** The diagram is where every fact goes first — as a node, a
+label beside a node, a branch condition, an error exit, an annotation stacked to the right. Before
+keeping a note, try to draw it; if it fits in the diagram, move it there and cut the note. What is
+left over is the material with no arrow: an inconsistency between two files, a reason stated in a
+code comment, a constraint that lives outside the call chain the diagram traces.
+
+**Two: the reader asked.** When they read the draft and ask "what does `.lean()` do here?" or "why
+two round trips?", that question is the section telling you what it is missing. Answer in chat, then
+fold the answer into Notes when you write the section, in the doc's own voice — not "you asked
+about X", just the explanation.
+
+The second source is why a first draft's Notes should be thin. Two or three notes is a normal draft;
+none at all is a legitimate draft and the block can be left out entirely. Resist explaining the Node
+and JS idioms up front, even though the reader is weak there and a diagram cannot hold them: you
+cannot tell which ones they already know, and a draft that answers eight guessed questions buries
+the one or two notes that are actually load-bearing. The questions they do ask are better evidence
+than your guess at them, and the review gate exists to collect them.
+
+When you revise a written section after the code changes, treat the notes already in it as answers
+the reader once asked for. Keep them unless the code they describe is gone.
+
+## Diagram conventions
+
+The diagram carries the flow; the prose carries what a diagram cannot express. Follow the diagrams
+already in the doc:
+
+- Flow runs downward with `│` and `▼`, starting at ` client`.
+- A node is `path/file.js:LINE` and, where useful, the function name beside it.
+- External calls go right with `──►`, with the URL and its query parameters stacked to the right.
+- Error exits go on the same line as their cause: `none → 400 "Outlook is not connected"`.
+- Branches use `├─` and `└─`, with the condition first and the outcome after `──►`.
+- A box `┌─┐` expands a sub-sequence inlined at that point.
+- Numbered stages `(1)`, `(2)` label branch points inside the diagram. They stand on their own; they
+  do not oblige you to write a Steps block, but they supply its numbering if one is asked for later.
+- One diagram per endpoint. A section covering two endpoints gets two diagrams.
+
+## Writing style
+
+**Do not editorialize.** Explain what the code does; do not offer a verdict on it. Phrasings like
+"the interesting bit", "this looks wasteful", "one thing to not mix up" were called out and removed.
+
+When the code has a reason, attribute it to the comment that states it rather than presenting it as
+your own reading:
+
+> The comment at `email.service.js:416` gives the reason: locating the attachment inside a message
+> fetched with this user's own token confirms it belongs to them.
+
+State anomalies as facts and let the reader draw the conclusion:
+
+> `getInbox` inlines the load-refresh-retry sequence that `withGraph()` (line 321) exists to hold.
+
+not "this is duplicated code that should be refactored."
+
+**Pitch to the reader.** They are strong in Python, SQL, Linux, relational and NoSQL databases,
+system design, data flow and ETL pipelines; weak in JavaScript, Node, npm and anything frontend.
+
+So when an explanation is called for — they asked, or you are writing Steps — the Node and JS idioms
+are what to spend it on: a promise deliberately not awaited, Mongoose `select: false`, a callback
+passed to a wrapper function, ESM default-export objects. Never spend it on database indexes, atomic
+updates, HTTP status codes or what a pipeline stage is; they know those better than you do.
+
+This tells you which explanations are worth writing, not that a draft should pre-empt them — see
+"What goes in Notes".
+
+Prefer short paragraphs over long ones, and concrete nouns over abstractions. Ordinary sentences,
+not bullet fragments, in Steps and Notes.
+
+## Before presenting
+
+Run the structure check on your draft:
+
+```bash
+python3 scripts/check_structure.py <path-to-ARCHITECTURE.md>          # all sections
+python3 scripts/check_structure.py <path-to-ARCHITECTURE.md> --section 3.5
+```
+
+It verifies the template is complete — description present and 15–35 words, Input/Output/Files,
+at least one diagram and `file:line` citations, with no banned editorializing phrases. Notes and
+Steps are both optional: a missing Notes block is reported as a warning rather than a failure, and a
+missing Steps block is not reported at all. If Steps are present their numbering must match the
+diagram. The check is shape only; accuracy is on you.
+
+Empty headings are reported as `empty` and are not failures — the doc is meant to be filled in
+gradually.

package/skills/architecture-walkthrough/references/sections.md

@@ -0,0 +1,29 @@
+# Sections, file inventories, and verified findings
+
+Paths below are relative to
+`/home/dev/workspaces/murtaza-workspaces/murtaza-hotel-project/Backend/src/`.
+
+## Doc state
+
+| Section | Title | Status |
+|---|---|---|
+| 1.1 | Registration | written |
+| 1.2 | Login | written |
+| 1.3 | Password reset | written |
+| 1.4 | Session validation | written |
+| 2.1 | Starting the connection | written |
+| 2.2 | OAuth callback and token storage | written |
+| 2.3 | Silent token refresh | written |
+| 2.4 | Connection status and disconnect | written |
+| 3.1 | Browsing the inbox | written |
+| 3.2 | Previewing an attachment | written |
+| 3.3 | Triggering extraction | written |
+| 3.4 | The extraction pipeline | written — spine plus 3.4.1–3.4.5 |
+| 3.5 | Reading a quotation | written |
+| 3.6 | Editing a quotation | written |
+| 3.7 | Exporting to Excel | written |
+| 3.8 | Exporting to PDF | written |
+| 3.9 | Sending the quotation by email | written |
+| — | Known issues (H2 at the end of the doc) | written |
+
+Re-derive this table from the doc rather than trusting it; sections get filled in between uses.

package/skills/architecture-walkthrough/scripts/check_structure.py

@@ -0,0 +1,200 @@
+#!/usr/bin/env python3
+"""Check that ARCHITECTURE.md sections follow the walkthrough template.
+
+Shape only — it cannot tell you whether a section is accurate. Empty headings are
+reported as `empty` and never fail, because the doc is filled in gradually. Notes and
+Steps are both optional; a missing Notes block is a warning, not a failure.
+
+    python3 check_structure.py path/to/ARCHITECTURE.md
+    python3 check_structure.py path/to/ARCHITECTURE.md --section 3.5
+    python3 check_structure.py path/to/ARCHITECTURE.md --json
+"""
+
+import argparse
+import json
+import re
+import sys
+
+DESC_LABEL = "**What this does for the business workflow:**"
+DESC_MIN, DESC_MAX = 15, 35
+
+ENDPOINT_RE = re.compile(r"`(GET|POST|PUT|PATCH|DELETE)\s+/")
+CITATION_RE = re.compile(r"[\w./-]+\.(?:js|mjs|json):\d+")
+STAGE_RE = re.compile(r"\((\d+)\)")
+STEP_RE = re.compile(r"^\*\*\((\d+)\)")
+FENCE_RE = re.compile(r"^```")
+
+# Phrasings the reader has asked to keep out: verdicts on the code rather than
+# descriptions of it.
+BANNED = [
+    "interesting bit",
+    "the interesting",
+    "looks wasteful",
+    "seems wasteful",
+    "not mix up",
+    "should be refactored",
+    "code smell",
+    "in my opinion",
+    "i think",
+    "arguably",
+    "unfortunately",
+    "sadly",
+    "cleverly",
+    "elegantly",
+    "surprisingly",
+    "oddly enough",
+    "the good news",
+    "the bad news",
+    "worth noting that",
+]
+
+
+def split_sections(text):
+    """Yield (number, title, body_lines) for every H3 heading."""
+    lines = text.splitlines()
+    starts = [
+        (i, m.group(1), m.group(2).strip())
+        for i, line in enumerate(lines)
+        if (m := re.match(r"^###\s+([\d.]+)\s+(.*)$", line))
+    ]
+    for pos, (idx, number, title) in enumerate(starts):
+        end = len(lines)
+        for j in range(idx + 1, len(lines)):
+            if lines[j].startswith("### ") or lines[j].startswith("## "):
+                end = j
+                break
+        if pos + 1 < len(starts):
+            end = min(end, starts[pos + 1][0])
+        yield number, title, lines[idx + 1 : end]
+
+
+def fenced_blocks(body):
+    blocks, current, inside = [], [], False
+    for line in body:
+        if FENCE_RE.match(line):
+            if inside:
+                blocks.append(current)
+                current, inside = [], False
+            else:
+                inside = True
+            continue
+        if inside:
+            current.append(line)
+    return blocks
+
+
+def description_words(body):
+    for i, line in enumerate(body):
+        if line.strip().startswith(DESC_LABEL):
+            para = [line.strip()[len(DESC_LABEL) :]]
+            for nxt in body[i + 1 :]:
+                if not nxt.strip():
+                    break
+                para.append(nxt)
+            return len(re.findall(r"[A-Za-z0-9][\w'`./:-]*", " ".join(para)))
+    return None
+
+
+def check(number, title, body):
+    text = "\n".join(body)
+    prose = "\n".join(
+        line for line in body if not line.startswith("```")
+    )  # banned-phrase scan includes diagrams; harmless
+
+    if not text.strip():
+        return {"section": number, "title": title, "status": "empty", "checks": []}
+
+    blocks = fenced_blocks(body)
+    words = description_words(body)
+    stages = sorted({int(n) for b in blocks for n in STAGE_RE.findall("\n".join(b))})
+    steps = sorted(int(m.group(1)) for line in body if (m := STEP_RE.match(line)))
+    lowered = prose.lower()
+    hits = [p for p in BANNED if p in lowered]
+
+    checks = [
+        ("business description present", "required", words is not None,
+         "add the `**What this does for the business workflow:**` line"),
+        (f"description is {DESC_MIN}-{DESC_MAX} words", "required",
+         words is not None and DESC_MIN <= words <= DESC_MAX,
+         f"description is {words} words"),
+        ("endpoint named", "required", bool(ENDPOINT_RE.search(text)),
+         "name the route as `METHOD /path`"),
+        ("Input stated", "required", "**Input:**" in text, "add an `**Input:**` line"),
+        ("Output stated", "required", "**Output:**" in text, "add an `**Output:**` line"),
+        ("Files listed", "required", "**Files:**" in text, "add a `**Files:**` line"),
+        ("diagram present", "required", len(blocks) > 0, "add the ASCII flow diagram"),
+        ("file:line citations", "required", bool(CITATION_RE.search(text)),
+         "cite file.js:LINE for the functions named"),
+        # Advisory, not required: Notes carry only what the diagram cannot and what the reader
+        # asked about, so a section with neither has nothing to say here. Failing the check would
+        # buy a filler paragraph.
+        ("Notes section", "advisory", "**Notes**" in text,
+         "no `**Notes**` block — fine if nothing qualified"),
+        ("no editorializing", "required", not hits,
+         f"banned phrasing: {', '.join(hits)}" if hits else ""),
+        # A Steps block is optional — the diagram plus Notes is the finished shape, and Steps are
+        # added only when the reader asks for more. So absence is fine; a mismatch is not.
+        ("Steps, if present, match the diagram numbering", "required",
+         (not steps) or (steps == stages),
+         f"diagram stages {stages} vs Steps {steps}"),
+    ]
+
+    results = [
+        {"name": name, "level": level, "passed": bool(ok), "detail": detail if not ok else ""}
+        for name, level, ok, detail in checks
+    ]
+    failed = any(r["level"] == "required" and not r["passed"] for r in results)
+    return {
+        "section": number,
+        "title": title,
+        "status": "fail" if failed else "pass",
+        "checks": results,
+    }
+
+
+def main():
+    ap = argparse.ArgumentParser()
+    ap.add_argument("path")
+    ap.add_argument("--section", help="check one section, e.g. 3.5")
+    ap.add_argument("--json", action="store_true")
+    args = ap.parse_args()
+
+    with open(args.path, encoding="utf-8") as fh:
+        text = fh.read()
+
+    results = [
+        check(num, title, body)
+        for num, title, body in split_sections(text)
+        if not args.section or num == args.section
+    ]
+
+    if not results:
+        print(f"no section matched {args.section!r}", file=sys.stderr)
+        return 2
+
+    if args.json:
+        print(json.dumps(results, indent=2))
+    else:
+        for r in results:
+            if r["status"] == "empty":
+                print(f"  ~  {r['section']} {r['title']}  (empty)")
+                continue
+            mark = "OK " if r["status"] == "pass" else "FAIL"
+            print(f"{mark:>4} {r['section']} {r['title']}")
+            for c in r["checks"]:
+                if c["passed"]:
+                    continue
+                tag = "fail" if c["level"] == "required" else "warn"
+                detail = f" — {c['detail']}" if c["detail"] else ""
+                print(f"       [{tag}] {c['name']}{detail}")
+
+        written = [r for r in results if r["status"] != "empty"]
+        bad = [r for r in written if r["status"] == "fail"]
+        print(f"\n{len(written) - len(bad)}/{len(written)} written sections pass "
+              f"({len(results) - len(written)} still empty)")
+
+    return 1 if any(r["status"] == "fail" for r in results) else 0
+
+
+if __name__ == "__main__":
+    sys.exit(main())

package/skills/autotest-webapp-ui/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: autotest-webapp-ui
+description: Automatically test webapp by controlling a chrome browser via CDP
+---
+
+# Permissions
+You have permission to:
+- start servers in a shell
+
+# Steps
+
+## Inform user
+- open inspect panel since CDP doesnt have tooling for it
+
+## Start servers
+- Start frontend & backend server
+
+## Inputs from user
+- CDP port - The port on which CDP listens for instructions to control chrome on another machine
+- screenshot frequency (default: last page) - as specified by user.
+- screenshot save path (default: skills/autotest-webapp-ui/autotest-webapp-ui-workspace/<YYYYMMDD-HHMMSS>/<path-n>) - save every run in a timestamped folder where each screenshot name is of format <screenshot-index>-<screenshot-slug> (eg: 01-login_page, 02-email_page)
+- save commands issued to CDP (default: no) - The raw commands sent to CDP to control chrome
+- save the logs from any of the Inspect panel subtabs (default: no): Logs from panels specified by user (Console, Network, Sources, Application, etc)
+
+## Preflight checks
+- Check Chrome control over CDP is working by opening google.com and closing it later
+
+## Traverse happy paths
+
+### Path-1
+- login with email `admin@gmail.com`, password `admin@123`
+- open emails
+- then click on the latest email
+- click on preview, wait for the preview to load
+- close the preview
+- click view quotation, wait for the next page to load
+- scroll the full page and come back to the top
+
+## Output
+- Create a .md file in the screenshot directory with following sections
+  - Path-n bullet points: copy paste these from above
+  - Path-n user flow diagram: Mermaid flowchart. Eg:
+    ```mermaid
+    graph LR
+    A(Start) -->B["<img src='<screenhot-01-path>' width='100' hegiht='100'/>"] -->C["<img src='<screenhot-02-path>' width='100' hegiht='100'/>"] -->D(End)
+    ```
+- Share screenshot path
+- Share paths for other inputs user said yes to
+
+## Ask user
+- what path they want to try next
+
+## Cleanup
+- Stop frontend & backend server
+
+# Constraints & alternatives
+- Do not write intermediate scripts to execute steps. Drive with one-shot commands
+- Do not make any changes to CDP port (eg: killing it, stopping it)